<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>

    C++ Standard Core Language
    
      Active Issues
     </TITLE>
</HEAD>
<BODY>
<TABLE ALIGN="RIGHT" CELLSPACING="0" CELLPADDING="0">
<TR>
<TD ALIGN="RIGHT">
      Document number:
     </TD>
<TD>
        &#160;WG21 N3806</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD>
<TD>
      &#160;2013-10-14</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Project:
     </TD>
<TD>
      &#160;Programming Language C++
     </TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Reference:
     </TD>
<TD>
      &#160;ISO/IEC IS 14882:2003
     </TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Reply to:
     </TD>
<TD>
      &#160;William M. Miller
     </TD>
</TR>
<TR>
<TD></TD>
<TD>
      &#160;Edison Design Group, Inc.
     </TD>
</TR>
<TR>
<TD></TD>
<TD>
      &#160;<A HREF="mailto://wmm@edg.com">wmm@edg.com</A></TD>
</TR>
</TABLE><BR CLEAR="ALL"><BR><CENTER>
<H2>

     C++ Standard Core Language
     
       Active Issues,
      

     Revision
     86</H2>
</CENTER><BR><P>
      This document contains the C++ core language issues on which the
      Committee (J16 + WG21) has not yet acted, that is, issues
      with status
      "<A HREF="#Ready Status">Ready</A>,"
      "<A HREF="#Tentatively Ready Status">Tentatively Ready</A>,"
      "<A HREF="#Review Status">Review</A>,"
      "<A HREF="#Drafting Status">Drafting</A>," and
      "<A HREF="#Open Status">Open</A>."
     </P>
<P>
    This document is part of a group of related documents that
    together describe the issues that have been raised regarding the
    C++ Standard.  The other documents in the group are:
   </P>
<UL>
<LI><A HREF="cwg_closed.html">Closed Issues List</A>, which contains
      the issues which the Committee has decided are not defects
      in the International Standard, including a brief rationale
      explaining the reason for the decision.
     </LI>
<LI><A HREF="cwg_defects.html">Defect Reports List</A>, which contains
      the issues that have been categorized by the Committee as Defect
      Reports, as well as other issues accepted by the Committee, along
      with their proposed resolutions.
     </LI>
<LI><A HREF="cwg_toc.html">Table of Contents</A>, which contains a
     summary listing of all issues in numerical order.
    </LI>
<LI><A HREF="cwg_index.html">Index by Section</A>, which contains a
     summary listing of all issues arranged in the order of the
     sections of the Standard with which they deal most directly.
    </LI>
<LI><A HREF="cwg_status.html">Index by Status</A>, which contains a
     summary listing of all issues grouped by status.
    </LI>
</UL>
<P>
    Section references in this document reflect the section numbering
    of document
    <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3690.pdf">WG21 N3690</A>.
   </P>
<P>The purpose of these documents is to record the disposition of issues
that have come before the Core Language Working Group of the ANSI
(INCITS PL22.16) and ISO (WG21) C++ Standard Committee.</P>

<P>Some issues represent potential defects in the ISO/IEC IS
14882:2011 document and corrected defects in the earlier 2003 and 1998
documents; others refer to text in the working draft for the next
revision of the C++ language and not to any Standard text.  Issues are
not necessarily formal ISO Defect Reports (DRs).  While some issues
will eventually be elevated to DR status, others will be disposed of
in other ways.  (See <A HREF="#Issue Status">Issue Status</A>
below.)</P>



<P>The most current public version of this document can be found at
<A HREF="http://www.open-std.org/jtc1/sc22/wg21">http://www.open-std.org/jtc1/sc22/wg21</A>. 
Requests for further information about these documents should include
the document number, reference ISO/IEC 14882:2011, and be
submitted to the InterNational Committee for Information Technology Standards
(INCITS),
1250&#160;Eye&#160;Street&#160;NW, Suite 200, Washington,&#160;DC&#160;20005,
USA.</P>

<P>Information regarding C++ standardization can be found at
<A HREF="http://isocpp.org/std">http://isocpp.org/std</A>.</P>

<BR>
<H3>Revision History</H3>

<UL>

<LI><B>Revision 86, 2013-10-14:</B> Reflected the deliberations of the
September, 2013 (Chicago) meeting.  Added new issues
<A HREF="
     cwg_active.html#1743">1743</A>,
<A HREF="
     cwg_active.html#1744">1744</A>,
<A HREF="
     cwg_active.html#1745">1745</A>,
<A HREF="
     cwg_active.html#1746">1746</A>,
<A HREF="
     cwg_active.html#1747">1747</A>,
<A HREF="
     cwg_active.html#1748">1748</A>,
<A HREF="
     cwg_active.html#1749">1749</A>,
<A HREF="
     cwg_active.html#1750">1750</A>,
<A HREF="
     cwg_active.html#1751">1751</A>,
<A HREF="
     cwg_active.html#1752">1752</A>,
<A HREF="
     cwg_active.html#1753">1753</A>,
<A HREF="
     cwg_active.html#1754">1754</A>,
<A HREF="
     cwg_active.html#1755">1755</A>,
<A HREF="
     cwg_active.html#1756">1756</A>,
<A HREF="
     cwg_active.html#1757">1757</A>,
<A HREF="
     cwg_active.html#1758">1758</A>,
<A HREF="
     cwg_active.html#1759">1759</A>,
<A HREF="
     cwg_active.html#1760">1760</A>,
<A HREF="
     cwg_active.html#1761">1761</A>,
<A HREF="
     cwg_active.html#1762">1762</A>,
<A HREF="
     cwg_active.html#1763">1763</A>,
<A HREF="
     cwg_active.html#1764">1764</A>,
<A HREF="
     cwg_active.html#1765">1765</A>,
<A HREF="
     cwg_active.html#1766">1766</A>,
<A HREF="
     cwg_active.html#1767">1767</A>,
<A HREF="
     cwg_active.html#1768">1768</A>,
<A HREF="
     cwg_active.html#1769">1769</A>,
<A HREF="
     cwg_active.html#1770">1770</A>,
<A HREF="
     cwg_active.html#1771">1771</A>,
<A HREF="
     cwg_active.html#1772">1772</A>,
<A HREF="
     cwg_active.html#1773">1773</A>,
<A HREF="
     cwg_active.html#1774">1774</A>,
<A HREF="
     cwg_active.html#1775">1775</A>,
<A HREF="
     cwg_active.html#1776">1776</A>,
<A HREF="
     cwg_active.html#1777">1777</A>,
<A HREF="
     cwg_active.html#1778">1778</A>,
<A HREF="
     cwg_active.html#1779">1779</A>,
<A HREF="
     cwg_active.html#1780">1780</A>,
<A HREF="
     cwg_active.html#1781">1781</A>,
<A HREF="
     cwg_active.html#1782">1782</A>,
<A HREF="
     cwg_active.html#1783">1783</A>,
<A HREF="
     cwg_active.html#1784">1784</A>,
<A HREF="
     cwg_active.html#1785">1785</A>,
<A HREF="
     cwg_active.html#1786">1786</A>,
<A HREF="
     cwg_active.html#1787">1787</A>,
<A HREF="
     cwg_active.html#1788">1788</A>,
<A HREF="
     cwg_active.html#1789">1789</A>,
<A HREF="
     cwg_active.html#1790">1790</A>,
<A HREF="
     cwg_active.html#1791">1791</A>,
<A HREF="
     cwg_active.html#1792">1792</A>,
<A HREF="
     cwg_active.html#1793">1793</A>,
<A HREF="
     cwg_active.html#1794">1794</A>, and
<A HREF="
     cwg_active.html#1795">1795</A>.
</LI>

<LI><B>Revision 85, 2013-09-03:</B> Incorporated the results of the
drafting review teleconferences held 2013-06-24 and 2013-08-26. Changed
the status of <A HREF="
     cwg_defects.html#583">issue 583</A> to "DR" because it
was (silently) addressed by N3624. Changed the status of
<A HREF="
     cwg_defects.html#1531">issue 1531</A> to "DR" because it had been
inadvertently overlooked in recording the motions of the April, 2013
meeting. Changed the status of <A HREF="
     cwg_defects.html#1597">issue 1597</A> to
"accepted" because it is moot after the adoption of N3652. Returned
<A HREF="
     cwg_active.html#1609">issue 1609</A> to "open" status in light of
additional discussion.  Added new information to the description of
<A HREF="
     cwg_active.html#1335">issue 1335</A>. Added new issues
<A HREF="
     cwg_closed.html#1657">1657</A>,
<A HREF="
     cwg_active.html#1658">1658</A>,
<A HREF="
     cwg_active.html#1659">1659</A>,
<A HREF="
     cwg_active.html#1660">1660</A>,
<A HREF="
     cwg_active.html#1661">1661</A>,
<A HREF="
     cwg_active.html#1662">1662</A>,
<A HREF="
     cwg_closed.html#1663">1663</A>,
<A HREF="
     cwg_active.html#1664">1664</A>,
<A HREF="
     cwg_active.html#1665">1665</A>,
<A HREF="
     cwg_active.html#1666">1666</A>,
<A HREF="
     cwg_closed.html#1667">1667</A>,
<A HREF="
     cwg_active.html#1668">1668</A>,
<A HREF="
     cwg_active.html#1669">1669</A>,
<A HREF="
     cwg_active.html#1670">1670</A>,
<A HREF="
     cwg_closed.html#1671">1671</A>,
<A HREF="
     cwg_active.html#1672">1672</A>,
<A HREF="
     cwg_active.html#1673">1673</A>,
<A HREF="
     cwg_active.html#1674">1674</A>,
<A HREF="
     cwg_active.html#1675">1675</A>,
<A HREF="
     cwg_active.html#1676">1676</A>,
<A HREF="
     cwg_active.html#1677">1677</A>,
<A HREF="
     cwg_closed.html#1678">1678</A>,
<A HREF="
     cwg_closed.html#1679">1679</A>,
<A HREF="
     cwg_active.html#1680">1680</A>,
<A HREF="
     cwg_active.html#1681">1681</A>,
<A HREF="
     cwg_active.html#1682">1682</A>,
<A HREF="
     cwg_active.html#1683">1683</A>,
<A HREF="
     cwg_active.html#1684">1684</A>,
<A HREF="
     cwg_active.html#1685">1685</A>,
<A HREF="
     cwg_active.html#1686">1686</A>,
<A HREF="
     cwg_active.html#1687">1687</A>,
<A HREF="
     cwg_closed.html#1688">1688</A>,
<A HREF="
     cwg_active.html#1689">1689</A>,
<A HREF="
     cwg_active.html#1690">1690</A>,
<A HREF="
     cwg_active.html#1691">1691</A>,
<A HREF="
     cwg_active.html#1692">1692</A>,
<A HREF="
     cwg_active.html#1693">1693</A>,
<A HREF="
     cwg_active.html#1694">1694</A>,
<A HREF="
     cwg_active.html#1695">1695</A>,
<A HREF="
     cwg_active.html#1696">1696</A>,
<A HREF="
     cwg_active.html#1697">1697</A>,
<A HREF="
     cwg_active.html#1698">1698</A>,
<A HREF="
     cwg_active.html#1699">1699</A>,
<A HREF="
     cwg_closed.html#1700">1700</A>,
<A HREF="
     cwg_active.html#1701">1701</A>,
<A HREF="
     cwg_active.html#1702">1702</A>,
<A HREF="
     cwg_closed.html#1703">1703</A>,
<A HREF="
     cwg_active.html#1704">1704</A>,
<A HREF="
     cwg_active.html#1705">1705</A>,
<A HREF="
     cwg_active.html#1706">1706</A>,
<A HREF="
     cwg_active.html#1707">1707</A>,
<A HREF="
     cwg_active.html#1708">1708</A>,
<A HREF="
     cwg_active.html#1709">1709</A>,
<A HREF="
     cwg_active.html#1710">1710</A>,
<A HREF="
     cwg_active.html#1711">1711</A>,
<A HREF="
     cwg_active.html#1712">1712</A>,
<A HREF="
     cwg_active.html#1713">1713</A>,
<A HREF="
     cwg_active.html#1714">1714</A>,
<A HREF="
     cwg_active.html#1715">1715</A>,
<A HREF="
     cwg_active.html#1716">1716</A>,
<A HREF="
     cwg_active.html#1717">1717</A>,
<A HREF="
     cwg_active.html#1718">1718</A>,
<A HREF="
     cwg_active.html#1719">1719</A>,
<A HREF="
     cwg_closed.html#1720">1720</A>,
<A HREF="
     cwg_active.html#1721">1721</A>,
<A HREF="
     cwg_active.html#1722">1722</A>,
<A HREF="
     cwg_active.html#1723">1723</A>,
<A HREF="
     cwg_active.html#1724">1724</A>,
<A HREF="
     cwg_closed.html#1725">1725</A>,
<A HREF="
     cwg_active.html#1726">1726</A>,
<A HREF="
     cwg_closed.html#1727">1727</A>,
<A HREF="
     cwg_active.html#1728">1728</A>,
<A HREF="
     cwg_active.html#1729">1729</A>,
<A HREF="
     cwg_active.html#1730">1730</A>,
<A HREF="
     cwg_closed.html#1731">1731</A>,
<A HREF="
     cwg_active.html#1732">1732</A>,
<A HREF="
     cwg_active.html#1733">1733</A>,
<A HREF="
     cwg_active.html#1734">1734</A>,
<A HREF="
     cwg_active.html#1735">1735</A>,
<A HREF="
     cwg_active.html#1736">1736</A>,
<A HREF="
     cwg_active.html#1737">1737</A>,
<A HREF="
     cwg_active.html#1738">1738</A>,
<A HREF="
     cwg_active.html#1739">1739</A>,
<A HREF="
     cwg_active.html#1740">1740</A>,
<A HREF="
     cwg_active.html#1741">1741</A>, and
<A HREF="
     cwg_active.html#1742">1742</A>.
</LI>

<LI><B>Revision 84, 2013-05-03:</B> Incorporated the results of the drafting
review teleconference held 2013-03-25 and the deliberations of the April, 2013
(Bristol) meeting.  Changed
<A HREF="
     cwg_closed.html#1568">issue 1568</A> to "dup" status.  Changed the
status of <A HREF="
     cwg_active.html#1492">issue 1492</A> to "drafting" status,
although it was approved as a DR at the meeting, because its resolution
is to be given by another resolution that was not moved.  Similarly,
issues <A HREF="
     cwg_active.html#1356">1356</A> and <A HREF="
     cwg_active.html#1465">1465</A>
were incorrectly moved as defect reports and have been returned to "review"
status awaiting the adoption of <A HREF="
     cwg_active.html#1351">issue 1351</A>.
Also, <A HREF="
     cwg_defects.html#1531">issue 1531</A> was moved as a DR but was
lacking the proposed resolution in the document in the pre-meeting mailing,
so it has been returned to "ready" status to be moved at the next meeting.
Changed the resolutions of issues <A HREF="
     cwg_defects.html#1374">1374</A> and
<A HREF="
     cwg_defects.html#1543">1543</A> to correct
clerical errors transcribing the original proposed resolutions.  Began the
practice of marking proposed resolutions as "[SUPERSEDED]" when a newer
one is added.
Added new issues
<A HREF="
     cwg_active.html#1642">1642</A>,
<A HREF="
     cwg_closed.html#1643">1643</A>,
<A HREF="
     cwg_active.html#1644">1644</A>,
<A HREF="
     cwg_active.html#1645">1645</A>,
<A HREF="
     cwg_active.html#1646">1646</A>,
<A HREF="
     cwg_active.html#1647">1647</A>,
<A HREF="
     cwg_defects.html#1648">1648</A>,
<A HREF="
     cwg_defects.html#1649">1649</A>,
<A HREF="
     cwg_active.html#1650">1650</A>,
<A HREF="
     cwg_active.html#1651">1651</A>,
<A HREF="
     cwg_active.html#1652">1652</A>,
<A HREF="
     cwg_active.html#1653">1653</A>,
<A HREF="
     cwg_closed.html#1654">1654</A>,
<A HREF="
     cwg_active.html#1655">1655</A>, and
<A HREF="
     cwg_active.html#1656">1656</A>.
</LI>

<LI><B>Revision 83, 2013-03-18:</B> Incorporated the results of the
drafting review teleconference held 2013-02-04, including moving
<A HREF="
     cwg_closed.html#1566">issue 1566</A> to "NAD" status.  Moved issues
<A HREF="
     cwg_defects.html#1417">1417</A> and <A HREF="
     cwg_defects.html#1460">1460</A> back to
"review" status in light of new questions.  Updated the &#8220;more
information&#8221; link to refer to <TT>isocpp.org</TT>.  Added new issues
<A HREF="
     cwg_closed.html#1606">1606</A>,
<A HREF="
     cwg_active.html#1607">1607</A>,
<A HREF="
     cwg_defects.html#1608">1608</A>,
<A HREF="
     cwg_active.html#1609">1609</A>,
<A HREF="
     cwg_active.html#1610">1610</A>,
<A HREF="
     cwg_active.html#1611">1611</A>,
<A HREF="
     cwg_active.html#1612">1612</A>,
<A HREF="
     cwg_active.html#1613">1613</A>,
<A HREF="
     cwg_active.html#1614">1614</A>,
<A HREF="
     cwg_active.html#1615">1615</A>,
<A HREF="
     cwg_active.html#1616">1616</A>,
<A HREF="
     cwg_active.html#1617">1617</A>,
<A HREF="
     cwg_defects.html#1618">1618</A>,
<A HREF="
     cwg_active.html#1619">1619</A>,
<A HREF="
     cwg_active.html#1620">1620</A>,
<A HREF="
     cwg_active.html#1621">1621</A>,
<A HREF="
     cwg_active.html#1622">1622</A>,
<A HREF="
     cwg_active.html#1623">1623</A>,
<A HREF="
     cwg_closed.html#1624">1624</A>,
<A HREF="
     cwg_active.html#1625">1625</A>,
<A HREF="
     cwg_active.html#1626">1626</A>,
<A HREF="
     cwg_closed.html#1627">1627</A>,
<A HREF="
     cwg_active.html#1628">1628</A>,
<A HREF="
     cwg_active.html#1629">1629</A>,
<A HREF="
     cwg_active.html#1630">1630</A>,
<A HREF="
     cwg_active.html#1631">1631</A>,
<A HREF="
     cwg_active.html#1632">1632</A>,
<A HREF="
     cwg_active.html#1633">1633</A>,
<A HREF="
     cwg_active.html#1634">1634</A>,
<A HREF="
     cwg_active.html#1635">1635</A>,
<A HREF="
     cwg_active.html#1636">1636</A>,
<A HREF="
     cwg_closed.html#1637">1637</A>,
<A HREF="
     cwg_active.html#1638">1638</A>,
<A HREF="
     cwg_active.html#1639">1639</A>,
<A HREF="
     cwg_active.html#1640">1640</A>, and
<A HREF="
     cwg_closed.html#1641">1641</A>.
</LI>

<LI><B>Revision 82, 2013-01-14:</B> Incorporated the results of the
drafting review teleconference held 2012-12-10.  Moved issues
<A HREF="
     cwg_defects.html#903">903</A>, <A HREF="
     cwg_defects.html#1213">1213</A>,
<A HREF="
     cwg_defects.html#1358">1358</A>,
<A HREF="
     cwg_active.html#1492">1492</A>, <A HREF="
     cwg_defects.html#1508">1508</A>,
and <A HREF="
     cwg_active.html#1552">1552</A> to "review" status to allow further
consideration in light of subsequent discussion.  Added new issues
<A HREF="
     cwg_defects.html#1569">1569</A>,
<A HREF="
     cwg_defects.html#1570">1570</A>,
<A HREF="
     cwg_active.html#1571">1571</A>,
<A HREF="
     cwg_active.html#1572">1572</A>,
<A HREF="
     cwg_active.html#1573">1573</A>,
<A HREF="
     cwg_closed.html#1574">1574</A>,
<A HREF="
     cwg_defects.html#1575">1575</A>,
<A HREF="
     cwg_defects.html#1576">1576</A>,
<A HREF="
     cwg_closed.html#1577">1577</A>,
<A HREF="
     cwg_closed.html#1578">1578</A>,
<A HREF="
     cwg_active.html#1579">1579</A>,
<A HREF="
     cwg_active.html#1580">1580</A>,
<A HREF="
     cwg_active.html#1581">1581</A>,
<A HREF="
     cwg_active.html#1582">1582</A>,
<A HREF="
     cwg_defects.html#1583">1583</A>,
<A HREF="
     cwg_active.html#1584">1584</A>,
<A HREF="
     cwg_closed.html#1585">1585</A>,
<A HREF="
     cwg_active.html#1586">1586</A>,
<A HREF="
     cwg_defects.html#1587">1587</A>,
<A HREF="
     cwg_defects.html#1588">1588</A>,
<A HREF="
     cwg_active.html#1589">1589</A>,
<A HREF="
     cwg_active.html#1590">1590</A>,
<A HREF="
     cwg_active.html#1591">1591</A>,
<A HREF="
     cwg_defects.html#1592">1592</A>,
<A HREF="
     cwg_defects.html#1593">1593</A>,
<A HREF="
     cwg_active.html#1594">1594</A>,
<A HREF="
     cwg_defects.html#1595">1595</A>,
<A HREF="
     cwg_active.html#1596">1596</A>,
<A HREF="
     cwg_defects.html#1597">1597</A>,
<A HREF="
     cwg_active.html#1598">1598</A>,
<A HREF="
     cwg_active.html#1599">1599</A>,
<A HREF="
     cwg_active.html#1600">1600</A>,
<A HREF="
     cwg_defects.html#1601">1601</A>,
<A HREF="
     cwg_active.html#1602">1602</A>,
<A HREF="
     cwg_active.html#1603">1603</A>,
<A HREF="
     cwg_active.html#1604">1604</A>, and
<A HREF="
     cwg_defects.html#1605">1605</A>.
</LI>

<LI><B>Revision 81, 2012-11-03:</B> Reflected the deliberations of the
October, 2012 (Portland) meeting.
Added new issues
<A HREF="
     cwg_defects.html#1560">1560</A>,
<A HREF="
     cwg_closed.html#1561">1561</A>,
<A HREF="
     cwg_defects.html#1562">1562</A>,
<A HREF="
     cwg_defects.html#1563">1563</A>,
<A HREF="
     cwg_closed.html#1564">1564</A>,
<A HREF="
     cwg_active.html#1565">1565</A>,
<A HREF="
     cwg_closed.html#1566">1566</A>,
<A HREF="
     cwg_defects.html#1567">1567</A>, and
<A HREF="
     cwg_closed.html#1568">1568</A>.
</LI>

<LI><B>Revision 80, 2012-09-24:</B> Added remaining descriptions omitted from
issues added in revision 77.  Corrected status of issues
<A HREF="
     cwg_defects.html#915">915</A>,
<A HREF="
     cwg_defects.html#1313">1313</A>, <A HREF="
     cwg_defects.html#1399">1399</A>, and
<A HREF="
     cwg_defects.html#1437">1437</A>. Changed the status of issues
<A HREF="
     cwg_defects.html#616">616</A>, <A HREF="
     cwg_defects.html#903">903</A>,
<A HREF="
     cwg_defects.html#1318">1318</A>, <A HREF="
     cwg_defects.html#1358">1358</A>, and
<A HREF="
     cwg_defects.html#1402">1402</A> in light of additional discussion.
Incorporated the results of the drafting review teleconference held
2012-08-13.  Moved <A HREF="
     cwg_closed.html#321">issue 321</A> to "dup" status.
Moved <A HREF="
     cwg_active.html#591">issue 591</A> to "open" status after the
discussion in "dup" <A HREF="
     cwg_closed.html#1526">issue 1526</A>.  Added additional
examples to <A HREF="
     cwg_closed.html#203">issue 203</A>.
Added new issues
<A HREF="
     cwg_active.html#1467">1467</A>,
<A HREF="
     cwg_active.html#1468">1468</A>,
<A HREF="
     cwg_active.html#1469">1469</A>,
<A HREF="
     cwg_closed.html#1470">1470</A>,
<A HREF="
     cwg_defects.html#1471">1471</A>,
<A HREF="
     cwg_defects.html#1472">1472</A>,
<A HREF="
     cwg_defects.html#1473">1473</A>,
<A HREF="
     cwg_closed.html#1474">1474</A>,
<A HREF="
     cwg_defects.html#1475">1475</A>,
<A HREF="
     cwg_defects.html#1476">1476</A>,
<A HREF="
     cwg_defects.html#1477">1477</A>,
<A HREF="
     cwg_active.html#1478">1478</A>,
<A HREF="
     cwg_defects.html#1479">1479</A>,
<A HREF="
     cwg_active.html#1480">1480</A>,
<A HREF="
     cwg_defects.html#1481">1481</A>,
<A HREF="
     cwg_defects.html#1482">1482</A>,
<A HREF="
     cwg_closed.html#1483">1483</A>,
<A HREF="
     cwg_active.html#1484">1484</A>,
<A HREF="
     cwg_active.html#1485">1485</A>,
<A HREF="
     cwg_active.html#1486">1486</A>,
<A HREF="
     cwg_defects.html#1487">1487</A>,
<A HREF="
     cwg_active.html#1488">1488</A>,
<A HREF="
     cwg_defects.html#1489">1489</A>,
<A HREF="
     cwg_active.html#1490">1490</A>,
<A HREF="
     cwg_active.html#1491">1491</A>,
<A HREF="
     cwg_active.html#1492">1492</A>,
<A HREF="
     cwg_active.html#1493">1493</A>,
<A HREF="
     cwg_defects.html#1494">1494</A>,
<A HREF="
     cwg_defects.html#1495">1495</A>,
<A HREF="
     cwg_active.html#1496">1496</A>,
<A HREF="
     cwg_closed.html#1497">1497</A>,
<A HREF="
     cwg_closed.html#1498">1498</A>,
<A HREF="
     cwg_active.html#1499">1499</A>,
<A HREF="
     cwg_active.html#1500">1500</A>,
<A HREF="
     cwg_closed.html#1501">1501</A>,
<A HREF="
     cwg_defects.html#1502">1502</A>,
<A HREF="
     cwg_defects.html#1503">1503</A>,
<A HREF="
     cwg_defects.html#1504">1504</A>,
<A HREF="
     cwg_closed.html#1505">1505</A>,
<A HREF="
     cwg_defects.html#1506">1506</A>,
<A HREF="
     cwg_defects.html#1507">1507</A>,
<A HREF="
     cwg_defects.html#1508">1508</A>,
<A HREF="
     cwg_defects.html#1509">1509</A>,
<A HREF="
     cwg_defects.html#1510">1510</A>,
<A HREF="
     cwg_defects.html#1511">1511</A>,
<A HREF="
     cwg_defects.html#1512">1512</A>,
<A HREF="
     cwg_active.html#1513">1513</A>,
<A HREF="
     cwg_defects.html#1514">1514</A>,
<A HREF="
     cwg_defects.html#1515">1515</A>,
<A HREF="
     cwg_defects.html#1516">1516</A>,
<A HREF="
     cwg_active.html#1517">1517</A>,
<A HREF="
     cwg_active.html#1518">1518</A>,
<A HREF="
     cwg_closed.html#1519">1519</A>,
<A HREF="
     cwg_closed.html#1520">1520</A>,
<A HREF="
     cwg_active.html#1521">1521</A>,
<A HREF="
     cwg_defects.html#1522">1522</A>,
<A HREF="
     cwg_active.html#1523">1523</A>,
<A HREF="
     cwg_active.html#1524">1524</A>,
<A HREF="
     cwg_closed.html#1525">1525</A>,
<A HREF="
     cwg_closed.html#1526">1526</A>,
<A HREF="
     cwg_defects.html#1527">1527</A>,
<A HREF="
     cwg_defects.html#1528">1528</A>,
<A HREF="
     cwg_active.html#1529">1529</A>,
<A HREF="
     cwg_active.html#1530">1530</A>,
<A HREF="
     cwg_defects.html#1531">1531</A>,
<A HREF="
     cwg_defects.html#1532">1532</A>,
<A HREF="
     cwg_defects.html#1533">1533</A>,
<A HREF="
     cwg_closed.html#1534">1534</A>,
<A HREF="
     cwg_defects.html#1535">1535</A>,
<A HREF="
     cwg_active.html#1536">1536</A>,
<A HREF="
     cwg_defects.html#1537">1537</A>,
<A HREF="
     cwg_defects.html#1538">1538</A>,
<A HREF="
     cwg_defects.html#1539">1539</A>,
<A HREF="
     cwg_closed.html#1540">1540</A>,
<A HREF="
     cwg_defects.html#1541">1541</A>,
<A HREF="
     cwg_active.html#1542">1542</A>,
<A HREF="
     cwg_defects.html#1543">1543</A>,
<A HREF="
     cwg_defects.html#1544">1544</A>,
<A HREF="
     cwg_active.html#1545">1545</A>,
<A HREF="
     cwg_closed.html#1546">1546</A>,
<A HREF="
     cwg_closed.html#1547">1547</A>,
<A HREF="
     cwg_active.html#1548">1548</A>,
<A HREF="
     cwg_active.html#1549">1549</A>,
<A HREF="
     cwg_defects.html#1550">1550</A>,
<A HREF="
     cwg_defects.html#1551">1551</A>,
<A HREF="
     cwg_active.html#1552">1552</A>,
<A HREF="
     cwg_defects.html#1553">1553</A>,
<A HREF="
     cwg_active.html#1554">1554</A>,
<A HREF="
     cwg_closed.html#1555">1555</A>,
<A HREF="
     cwg_defects.html#1556">1556</A>,
<A HREF="
     cwg_defects.html#1557">1557</A>,
<A HREF="
     cwg_active.html#1558">1558</A>, and
<A HREF="
     cwg_defects.html#1559">1559</A>.
</LI>

<LI><B>Revision 79, 2012-02-27:</B> Reflected deliberations at the
February, 2012 (Kona) meeting.
Added descriptions omitted from some issues
added in revision 77.  Moved <A HREF="
     cwg_closed.html#1427">issue 1427</A> to
"NAD" status. Moved <A HREF="
     cwg_closed.html#1377">issue 1377</A> to "dup" status
(with respect to <A HREF="
     cwg_active.html#1279">issue 1279</A>).
Moved <A HREF="
     cwg_closed.html#1422">issue 1422</A> to "dup"
status (with respect to <A HREF="
     cwg_defects.html#912">issue 912</A>). Added a
new status, "concurrency", to track issues that will be considered and
resolved by the Concurrency Working Group.
Added new issues
<A HREF="
     cwg_active.html#1444">1444</A>,
<A HREF="
     cwg_closed.html#1445">1445</A>,
<A HREF="
     cwg_active.html#1446">1446</A>,
<A HREF="
     cwg_defects.html#1447">1447</A>,
<A HREF="
     cwg_closed.html#1448">1448</A>,
<A HREF="
     cwg_defects.html#1449">1449</A>,
<A HREF="
     cwg_defects.html#1450">1450</A>,
<A HREF="
     cwg_closed.html#1451">1451</A>,
<A HREF="
     cwg_active.html#1452">1452</A>,
<A HREF="
     cwg_defects.html#1453">1453</A>,
<A HREF="
     cwg_defects.html#1454">1454</A>,
<A HREF="
     cwg_defects.html#1455">1455</A>,
<A HREF="
     cwg_defects.html#1456">1456</A>,
<A HREF="
     cwg_defects.html#1457">1457</A>,
<A HREF="
     cwg_defects.html#1458">1458</A>,
<A HREF="
     cwg_active.html#1459">1459</A>,
<A HREF="
     cwg_defects.html#1460">1460</A>,
<A HREF="
     cwg_closed.html#1461">1461</A>,
<A HREF="
     cwg_defects.html#1462">1462</A>,
<A HREF="
     cwg_closed.html#1463">1463</A>,
<A HREF="
     cwg_defects.html#1464">1464</A>,
<A HREF="
     cwg_active.html#1465">1465</A>, and
<A HREF="
     cwg_active.html#1466">1466</A>.
</LI>

<LI><B>Revision 78, 2012-01-17:</B> Reflected the results of the
December 5, 2011 teleconference.
Changed the status of issues
<A HREF="
     cwg_defects.html#496">496</A>,
<A HREF="
     cwg_defects.html#675">675</A>,
<A HREF="
     cwg_defects.html#739">739</A>,
<A HREF="
     cwg_defects.html#1268">1268</A>,
<A HREF="
     cwg_defects.html#1269">1269</A>,
<A HREF="
     cwg_defects.html#1287">1287</A>, and
<A HREF="
     cwg_defects.html#1312">1312</A> from "ready" to "review" in response to
further discussion of the proposed resolutions.
Added new issues
<A HREF="
     cwg_defects.html#1370">1370</A>,
<A HREF="
     cwg_closed.html#1371">1371</A>,
<A HREF="
     cwg_defects.html#1372">1372</A>,
<A HREF="
     cwg_closed.html#1373">1373</A>,
<A HREF="
     cwg_defects.html#1374">1374</A>,
<A HREF="
     cwg_defects.html#1375">1375</A>,
<A HREF="
     cwg_active.html#1376">1376</A>,
<A HREF="
     cwg_closed.html#1377">1377</A>,
<A HREF="
     cwg_active.html#1378">1378</A>,
<A HREF="
     cwg_closed.html#1379">1379</A>,
<A HREF="
     cwg_defects.html#1380">1380</A>,
<A HREF="
     cwg_defects.html#1381">1381</A>,
<A HREF="
     cwg_defects.html#1382">1382</A>,
<A HREF="
     cwg_defects.html#1383">1383</A>,
<A HREF="
     cwg_closed.html#1384">1384</A>,
<A HREF="
     cwg_defects.html#1385">1385</A>,
<A HREF="
     cwg_closed.html#1386">1386</A>,
<A HREF="
     cwg_defects.html#1387">1387</A>,
<A HREF="
     cwg_defects.html#1388">1388</A>,
<A HREF="
     cwg_closed.html#1389">1389</A>,
<A HREF="
     cwg_active.html#1390">1390</A>,
<A HREF="
     cwg_active.html#1391">1391</A>,
<A HREF="
     cwg_defects.html#1392">1392</A>,
<A HREF="
     cwg_closed.html#1393">1393</A>,
<A HREF="
     cwg_defects.html#1394">1394</A>,
<A HREF="
     cwg_active.html#1395">1395</A>,
<A HREF="
     cwg_active.html#1396">1396</A>,
<A HREF="
     cwg_active.html#1397">1397</A>,
<A HREF="
     cwg_defects.html#1398">1398</A>,
<A HREF="
     cwg_defects.html#1399">1399</A>,
<A HREF="
     cwg_closed.html#1400">1400</A>,
<A HREF="
     cwg_defects.html#1401">1401</A>,
<A HREF="
     cwg_defects.html#1402">1402</A>,
<A HREF="
     cwg_active.html#1403">1403</A>,
<A HREF="
     cwg_active.html#1404">1404</A>,
<A HREF="
     cwg_defects.html#1405">1405</A>,
<A HREF="
     cwg_defects.html#1406">1406</A>,
<A HREF="
     cwg_closed.html#1407">1407</A>,
<A HREF="
     cwg_defects.html#1408">1408</A>,
<A HREF="
     cwg_defects.html#1409">1409</A>,
<A HREF="
     cwg_defects.html#1410">1410</A>,
<A HREF="
     cwg_defects.html#1411">1411</A>,
<A HREF="
     cwg_defects.html#1412">1412</A>,
<A HREF="
     cwg_defects.html#1413">1413</A>,
<A HREF="
     cwg_active.html#1414">1414</A>,
<A HREF="
     cwg_defects.html#1415">1415</A>,
<A HREF="
     cwg_defects.html#1416">1416</A>,
<A HREF="
     cwg_defects.html#1417">1417</A>,
<A HREF="
     cwg_defects.html#1418">1418</A>,
<A HREF="
     cwg_closed.html#1419">1419</A>,
<A HREF="
     cwg_closed.html#1420">1420</A>,
<A HREF="
     cwg_closed.html#1421">1421</A>,
<A HREF="
     cwg_closed.html#1422">1422</A>,
<A HREF="
     cwg_defects.html#1423">1423</A>,
<A HREF="
     cwg_defects.html#1424">1424</A>,
<A HREF="
     cwg_defects.html#1425">1425</A>,
<A HREF="
     cwg_closed.html#1426">1426</A>,
<A HREF="
     cwg_closed.html#1427">1427</A>,
<A HREF="
     cwg_defects.html#1428">1428</A>,
<A HREF="
     cwg_closed.html#1429">1429</A>,
<A HREF="
     cwg_active.html#1430">1430</A>,
<A HREF="
     cwg_defects.html#1431">1431</A>,
<A HREF="
     cwg_active.html#1432">1432</A>,
<A HREF="
     cwg_closed.html#1433">1433</A>,
<A HREF="
     cwg_closed.html#1434">1434</A>,
<A HREF="
     cwg_defects.html#1435">1435</A>,
<A HREF="
     cwg_active.html#1436">1436</A>,
<A HREF="
     cwg_defects.html#1437">1437</A>,
<A HREF="
     cwg_defects.html#1438">1438</A>,
<A HREF="
     cwg_defects.html#1439">1439</A>,
<A HREF="
     cwg_defects.html#1440">1440</A>,
<A HREF="
     cwg_active.html#1441">1441</A>,
<A HREF="
     cwg_defects.html#1442">1442</A>, and
<A HREF="
     cwg_closed.html#1443">1443</A>.
</LI>

<LI><B>Revision 77, 2011-09-06:</B> Reflected the deliberations of the
August, 2011 (Bloomington) meeting.  Added new issues
<A HREF="
     cwg_active.html#1247">1247</A>,
<A HREF="
     cwg_active.html#1248">1248</A>,
<A HREF="
     cwg_active.html#1249">1249</A>,
<A HREF="
     cwg_defects.html#1250">1250</A>,
<A HREF="
     cwg_defects.html#1251">1251</A>,
<A HREF="
     cwg_active.html#1252">1252</A>,
<A HREF="
     cwg_active.html#1253">1253</A>,
<A HREF="
     cwg_closed.html#1254">1254</A>,
<A HREF="
     cwg_active.html#1255">1255</A>,
<A HREF="
     cwg_active.html#1256">1256</A>,
<A HREF="
     cwg_active.html#1257">1257</A>,
<A HREF="
     cwg_active.html#1258">1258</A>,
<A HREF="
     cwg_closed.html#1259">1259</A>,
<A HREF="
     cwg_defects.html#1260">1260</A>,
<A HREF="
     cwg_defects.html#1261">1261</A>,
<A HREF="
     cwg_defects.html#1262">1262</A>,
<A HREF="
     cwg_closed.html#1263">1263</A>,
<A HREF="
     cwg_defects.html#1264">1264</A>,
<A HREF="
     cwg_defects.html#1265">1265</A>,
<A HREF="
     cwg_active.html#1266">1266</A>,
<A HREF="
     cwg_defects.html#1267">1267</A>,
<A HREF="
     cwg_defects.html#1268">1268</A>,
<A HREF="
     cwg_defects.html#1269">1269</A>,
<A HREF="
     cwg_defects.html#1270">1270</A>,
<A HREF="
     cwg_active.html#1271">1271</A>,
<A HREF="
     cwg_closed.html#1272">1272</A>,
<A HREF="
     cwg_closed.html#1273">1273</A>,
<A HREF="
     cwg_active.html#1274">1274</A>,
<A HREF="
     cwg_defects.html#1275">1275</A>,
<A HREF="
     cwg_closed.html#1276">1276</A>,
<A HREF="
     cwg_closed.html#1277">1277</A>,
<A HREF="
     cwg_active.html#1278">1278</A>,
<A HREF="
     cwg_active.html#1279">1279</A>,
<A HREF="
     cwg_closed.html#1280">1280</A>,
<A HREF="
     cwg_closed.html#1281">1281</A>,
<A HREF="
     cwg_defects.html#1282">1282</A>,
<A HREF="
     cwg_active.html#1283">1283</A>,
<A HREF="
     cwg_active.html#1284">1284</A>,
<A HREF="
     cwg_active.html#1285">1285</A>,
<A HREF="
     cwg_active.html#1286">1286</A>,
<A HREF="
     cwg_defects.html#1287">1287</A>,
<A HREF="
     cwg_defects.html#1288">1288</A>,
<A HREF="
     cwg_closed.html#1289">1289</A>,
<A HREF="
     cwg_defects.html#1290">1290</A>,
<A HREF="
     cwg_active.html#1291">1291</A>,
<A HREF="
     cwg_active.html#1292">1292</A>,
<A HREF="
     cwg_defects.html#1293">1293</A>,
<A HREF="
     cwg_active.html#1294">1294</A>,
<A HREF="
     cwg_defects.html#1295">1295</A>,
<A HREF="
     cwg_defects.html#1296">1296</A>,
<A HREF="
     cwg_defects.html#1297">1297</A>,
<A HREF="
     cwg_defects.html#1298">1298</A>,
<A HREF="
     cwg_active.html#1299">1299</A>,
<A HREF="
     cwg_closed.html#1300">1300</A>,
<A HREF="
     cwg_defects.html#1301">1301</A>,
<A HREF="
     cwg_defects.html#1302">1302</A>,
<A HREF="
     cwg_closed.html#1303">1303</A>,
<A HREF="
     cwg_active.html#1304">1304</A>,
<A HREF="
     cwg_defects.html#1305">1305</A>,
<A HREF="
     cwg_defects.html#1306">1306</A>,
<A HREF="
     cwg_defects.html#1307">1307</A>,
<A HREF="
     cwg_defects.html#1308">1308</A>,
<A HREF="
     cwg_active.html#1309">1309</A>,
<A HREF="
     cwg_defects.html#1310">1310</A>,
<A HREF="
     cwg_defects.html#1311">1311</A>,
<A HREF="
     cwg_defects.html#1312">1312</A>,
<A HREF="
     cwg_defects.html#1313">1313</A>,
<A HREF="
     cwg_closed.html#1314">1314</A>,
<A HREF="
     cwg_active.html#1315">1315</A>,
<A HREF="
     cwg_closed.html#1316">1316</A>,
<A HREF="
     cwg_closed.html#1317">1317</A>,
<A HREF="
     cwg_defects.html#1318">1318</A>,
<A HREF="
     cwg_closed.html#1319">1319</A>,
<A HREF="
     cwg_defects.html#1320">1320</A>,
<A HREF="
     cwg_defects.html#1321">1321</A>,
<A HREF="
     cwg_active.html#1322">1322</A>,
<A HREF="
     cwg_closed.html#1323">1323</A>,
<A HREF="
     cwg_defects.html#1324">1324</A>,
<A HREF="
     cwg_active.html#1325">1325</A>,
<A HREF="
     cwg_closed.html#1326">1326</A>,
<A HREF="
     cwg_defects.html#1327">1327</A>,
<A HREF="
     cwg_defects.html#1328">1328</A>,
<A HREF="
     cwg_defects.html#1329">1329</A>,
<A HREF="
     cwg_defects.html#1330">1330</A>,
<A HREF="
     cwg_closed.html#1331">1331</A>,
<A HREF="
     cwg_active.html#1332">1332</A>,
<A HREF="
     cwg_defects.html#1333">1333</A>,
<A HREF="
     cwg_closed.html#1334">1334</A>,
<A HREF="
     cwg_active.html#1335">1335</A>,
<A HREF="
     cwg_defects.html#1336">1336</A>,
<A HREF="
     cwg_closed.html#1337">1337</A>,
<A HREF="
     cwg_active.html#1338">1338</A>,
<A HREF="
     cwg_closed.html#1339">1339</A>,
<A HREF="
     cwg_defects.html#1340">1340</A>,
<A HREF="
     cwg_active.html#1341">1341</A>,
<A HREF="
     cwg_active.html#1342">1342</A>,
<A HREF="
     cwg_active.html#1343">1343</A>,
<A HREF="
     cwg_active.html#1344">1344</A>,
<A HREF="
     cwg_defects.html#1345">1345</A>,
<A HREF="
     cwg_defects.html#1346">1346</A>,
<A HREF="
     cwg_defects.html#1347">1347</A>,
<A HREF="
     cwg_active.html#1348">1348</A>,
<A HREF="
     cwg_active.html#1349">1349</A>,
<A HREF="
     cwg_defects.html#1350">1350</A>,
<A HREF="
     cwg_active.html#1351">1351</A>,
<A HREF="
     cwg_defects.html#1352">1352</A>,
<A HREF="
     cwg_active.html#1353">1353</A>,
<A HREF="
     cwg_defects.html#1354">1354</A>,
<A HREF="
     cwg_defects.html#1355">1355</A>,
<A HREF="
     cwg_active.html#1356">1356</A>,
<A HREF="
     cwg_defects.html#1357">1357</A>,
<A HREF="
     cwg_defects.html#1358">1358</A>,
<A HREF="
     cwg_defects.html#1359">1359</A>,
<A HREF="
     cwg_active.html#1360">1360</A>,
<A HREF="
     cwg_defects.html#1361">1361</A>,
<A HREF="
     cwg_defects.html#1362">1362</A>,
<A HREF="
     cwg_defects.html#1363">1363</A>,
<A HREF="
     cwg_defects.html#1364">1364</A>,
<A HREF="
     cwg_defects.html#1365">1365</A>,
<A HREF="
     cwg_defects.html#1366">1366</A>,
<A HREF="
     cwg_defects.html#1367">1367</A>,
<A HREF="
     cwg_defects.html#1368">1368</A>, and
<A HREF="
     cwg_defects.html#1369">1369</A>.
(Note that many of the preceding issues are missing descriptions.
These will be provided in the next revision of the issues list.)
</LI>

<LI><B>Revision 76, 2011-04-10:</B> Reflected the results of the March
7, 2011 teleconference and the March, 2011 (Madrid) meeting, including
adding a new status, "FDIS," for issues that are resolved in the draft
advanced at that meeting for FDIS balloting. In respect for ISO rules
governing work during the balloting process, no new issues have been
included in this version of the list.</LI>

<LI><B>Revision 75, 2011-02-28:</B> Reflected results of two
between-meetings teleconferences, including moving a number of issues
to "tentatively ready" status.  Added drafting for a number of issues
and moved them to "review" status.  Reopened <A HREF="
     cwg_closed.html#109">issue 109</A> in light of recent discussion.  Moved <A HREF="
     cwg_active.html#1028">issue 1028</A> back to "open" status after further analysis.  Moved
issues <A HREF="
     cwg_defects.html#1109">1109</A> and <A HREF="
     cwg_defects.html#1127">1127</A>
to "DR" status, as they had been overlooked in the results of the
November, 2010 (Batavia) meeting.  Added new issues
<A HREF="
     cwg_defects.html#1227">1227</A>,
<A HREF="
     cwg_closed.html#1228">1228</A>,
<A HREF="
     cwg_defects.html#1229">1229</A>,
<A HREF="
     cwg_active.html#1230">1230</A>,
<A HREF="
     cwg_defects.html#1231">1231</A>,
<A HREF="
     cwg_defects.html#1232">1232</A>,
<A HREF="
     cwg_defects.html#1233">1233</A>,
<A HREF="
     cwg_defects.html#1234">1234</A>,
<A HREF="
     cwg_defects.html#1235">1235</A>,
<A HREF="
     cwg_defects.html#1236">1236</A>,
<A HREF="
     cwg_defects.html#1237">1237</A>,
<A HREF="
     cwg_defects.html#1238">1238</A>,
<A HREF="
     cwg_defects.html#1239">1239</A>,
<A HREF="
     cwg_defects.html#1240">1240</A>,
<A HREF="
     cwg_defects.html#1241">1241</A>,
<A HREF="
     cwg_defects.html#1242">1242</A>,
<A HREF="
     cwg_defects.html#1243">1243</A>,
<A HREF="
     cwg_defects.html#1244">1244</A>,
<A HREF="
     cwg_defects.html#1245">1245</A>, and
<A HREF="
     cwg_defects.html#1246">1246</A>.
</LI>

<LI><B>Revision 74, 2010-11-29:</B> Reflected deliberations at the
November, 2010 (Batavia) meeting.  Added new issues
<A HREF="
     cwg_active.html#1211">1211</A>,
<A HREF="
     cwg_defects.html#1212">1212</A>,
<A HREF="
     cwg_defects.html#1213">1213</A>,
<A HREF="
     cwg_defects.html#1214">1214</A>,
<A HREF="
     cwg_defects.html#1215">1215</A>,
<A HREF="
     cwg_defects.html#1216">1216</A>,
<A HREF="
     cwg_closed.html#1217">1217</A>,
<A HREF="
     cwg_defects.html#1218">1218</A>,
<A HREF="
     cwg_defects.html#1219">1219</A>,
<A HREF="
     cwg_defects.html#1220">1220</A>,
<A HREF="
     cwg_active.html#1221">1221</A>,
<A HREF="
     cwg_closed.html#1222">1222</A>,
<A HREF="
     cwg_active.html#1223">1223</A>,
<A HREF="
     cwg_defects.html#1224">1224</A>,
<A HREF="
     cwg_defects.html#1225">1225</A>, and
<A HREF="
     cwg_defects.html#1226">1226</A>.
</LI>

<LI><B>Revision 73, 2010-10-18:</B> Moved issues
<A HREF="
     cwg_defects.html#994">994</A> and <A HREF="
     cwg_closed.html#1058">1058</A>
back to "open" status for potential reconsideration. Added analysis to
<A HREF="
     cwg_active.html#1038">issue 1038</A>. Moved issues
<A HREF="
     cwg_defects.html#1125">1125</A> and <A HREF="
     cwg_defects.html#1127">1127</A>
back to "drafting" status after further discussion revealed problems
with the proposed resolution approved at the August, 2010 meeting.
Moved <A HREF="
     cwg_defects.html#1167">issue 1167</A> to "review" status to
allow consideration of extending the resolution to cover a new but
related question. Reflected results of two between-meetings teleconferences,
including moving a number of issues to "tentatively ready" status.
Added new issues
<A HREF="
     cwg_defects.html#1174">1174</A>,
<A HREF="
     cwg_defects.html#1175">1175</A>,
<A HREF="
     cwg_defects.html#1176">1176</A>,
<A HREF="
     cwg_defects.html#1177">1177</A>,
<A HREF="
     cwg_defects.html#1178">1178</A>,
<A HREF="
     cwg_closed.html#1179">1179</A>,
<A HREF="
     cwg_defects.html#1180">1180</A>,
<A HREF="
     cwg_defects.html#1181">1181</A>,
<A HREF="
     cwg_defects.html#1182">1182</A>,
<A HREF="
     cwg_defects.html#1183">1183</A>,
<A HREF="
     cwg_defects.html#1184">1184</A>,
<A HREF="
     cwg_defects.html#1185">1185</A>,
<A HREF="
     cwg_defects.html#1186">1186</A>,
<A HREF="
     cwg_defects.html#1187">1187</A>,
<A HREF="
     cwg_defects.html#1188">1188</A>,
<A HREF="
     cwg_defects.html#1189">1189</A>,
<A HREF="
     cwg_defects.html#1190">1190</A>,
<A HREF="
     cwg_defects.html#1191">1191</A>,
<A HREF="
     cwg_defects.html#1192">1192</A>,
<A HREF="
     cwg_defects.html#1193">1193</A>,
<A HREF="
     cwg_defects.html#1194">1194</A>,
<A HREF="
     cwg_defects.html#1195">1195</A>,
<A HREF="
     cwg_defects.html#1196">1196</A>,
<A HREF="
     cwg_defects.html#1197">1197</A>,
<A HREF="
     cwg_defects.html#1198">1198</A>,
<A HREF="
     cwg_defects.html#1199">1199</A>,
<A HREF="
     cwg_active.html#1200">1200</A>,
<A HREF="
     cwg_defects.html#1201">1201</A>,
<A HREF="
     cwg_defects.html#1202">1202</A>,
<A HREF="
     cwg_closed.html#1203">1203</A>,
<A HREF="
     cwg_defects.html#1204">1204</A>,
<A HREF="
     cwg_closed.html#1205">1205</A>,
<A HREF="
     cwg_defects.html#1206">1206</A>,
<A HREF="
     cwg_defects.html#1207">1207</A>,
<A HREF="
     cwg_defects.html#1208">1208</A>,
<A HREF="
     cwg_active.html#1209">1209</A>, and
<A HREF="
     cwg_defects.html#1210">1210</A>,
</LI>

<LI><B>Revision 72, 2010-08-23:</B> Reflected deliberations at the
August, 2010 (Rapperswil) meeting. Added new issues
<A HREF="
     cwg_defects.html#1091">1091</A>,
<A HREF="
     cwg_active.html#1092">1092</A>,
<A HREF="
     cwg_defects.html#1093">1093</A>,
<A HREF="
     cwg_defects.html#1094">1094</A>,
<A HREF="
     cwg_defects.html#1095">1095</A>,
<A HREF="
     cwg_defects.html#1096">1096</A>,
<A HREF="
     cwg_closed.html#1097">1097</A>,
<A HREF="
     cwg_defects.html#1098">1098</A>,
<A HREF="
     cwg_defects.html#1099">1099</A>,
<A HREF="
     cwg_defects.html#1100">1100</A>,
<A HREF="
     cwg_defects.html#1101">1101</A>,
<A HREF="
     cwg_defects.html#1102">1102</A>,
<A HREF="
     cwg_defects.html#1103">1103</A>,
<A HREF="
     cwg_defects.html#1104">1104</A>,
<A HREF="
     cwg_defects.html#1105">1105</A>,
<A HREF="
     cwg_defects.html#1106">1106</A>,
<A HREF="
     cwg_defects.html#1107">1107</A>,
<A HREF="
     cwg_closed.html#1108">1108</A>,
<A HREF="
     cwg_defects.html#1109">1109</A>,
<A HREF="
     cwg_closed.html#1110">1110</A>,
<A HREF="
     cwg_defects.html#1111">1111</A>,
<A HREF="
     cwg_defects.html#1112">1112</A>,
<A HREF="
     cwg_defects.html#1113">1113</A>,
<A HREF="
     cwg_defects.html#1114">1114</A>,
<A HREF="
     cwg_defects.html#1115">1115</A>,
<A HREF="
     cwg_active.html#1116">1116</A>,
<A HREF="
     cwg_defects.html#1117">1117</A>,
<A HREF="
     cwg_closed.html#1118">1118</A>,
<A HREF="
     cwg_defects.html#1119">1119</A>,
<A HREF="
     cwg_defects.html#1120">1120</A>,
<A HREF="
     cwg_defects.html#1121">1121</A>,
<A HREF="
     cwg_defects.html#1122">1122</A>,
<A HREF="
     cwg_defects.html#1123">1123</A>,
<A HREF="
     cwg_closed.html#1124">1124</A>,
<A HREF="
     cwg_defects.html#1125">1125</A>,
<A HREF="
     cwg_defects.html#1126">1126</A>,
<A HREF="
     cwg_defects.html#1127">1127</A>,
<A HREF="
     cwg_defects.html#1128">1128</A>,
<A HREF="
     cwg_defects.html#1129">1129</A>,
<A HREF="
     cwg_defects.html#1130">1130</A>,
<A HREF="
     cwg_defects.html#1131">1131</A>,
<A HREF="
     cwg_closed.html#1132">1132</A>,
<A HREF="
     cwg_defects.html#1133">1133</A>,
<A HREF="
     cwg_defects.html#1134">1134</A>,
<A HREF="
     cwg_defects.html#1135">1135</A>,
<A HREF="
     cwg_defects.html#1136">1136</A>,
<A HREF="
     cwg_defects.html#1137">1137</A>,
<A HREF="
     cwg_defects.html#1138">1138</A>,
<A HREF="
     cwg_defects.html#1139">1139</A>,
<A HREF="
     cwg_defects.html#1140">1140</A>,
<A HREF="
     cwg_closed.html#1141">1141</A>,
<A HREF="
     cwg_defects.html#1142">1142</A>,
<A HREF="
     cwg_closed.html#1143">1143</A>,
<A HREF="
     cwg_defects.html#1144">1144</A>,
<A HREF="
     cwg_defects.html#1145">1145</A>,
<A HREF="
     cwg_defects.html#1146">1146</A>,
<A HREF="
     cwg_defects.html#1147">1147</A>,
<A HREF="
     cwg_defects.html#1148">1148</A>,
<A HREF="
     cwg_defects.html#1149">1149</A>,
<A HREF="
     cwg_closed.html#1150">1150</A>,
<A HREF="
     cwg_defects.html#1151">1151</A>,
<A HREF="
     cwg_defects.html#1152">1152</A>,
<A HREF="
     cwg_defects.html#1153">1153</A>,
<A HREF="
     cwg_defects.html#1154">1154</A>,
<A HREF="
     cwg_defects.html#1155">1155</A>,
<A HREF="
     cwg_defects.html#1156">1156</A>,
<A HREF="
     cwg_active.html#1157">1157</A>,
<A HREF="
     cwg_defects.html#1158">1158</A>,
<A HREF="
     cwg_defects.html#1159">1159</A>,
<A HREF="
     cwg_defects.html#1160">1160</A>,
<A HREF="
     cwg_defects.html#1161">1161</A>,
<A HREF="
     cwg_closed.html#1162">1162</A>,
<A HREF="
     cwg_closed.html#1163">1163</A>,
<A HREF="
     cwg_defects.html#1164">1164</A>,
<A HREF="
     cwg_defects.html#1165">1165</A>,
<A HREF="
     cwg_defects.html#1166">1166</A>,
<A HREF="
     cwg_defects.html#1167">1167</A>,
<A HREF="
     cwg_defects.html#1168">1168</A>,
<A HREF="
     cwg_defects.html#1169">1169</A>,
<A HREF="
     cwg_defects.html#1170">1170</A>,
<A HREF="
     cwg_defects.html#1171">1171</A>,
<A HREF="
     cwg_active.html#1172">1172</A>, and
<A HREF="
     cwg_defects.html#1173">1173</A>.
</LI>

<LI><B>Revision 71, 2010-08-07:</B> Added new issues
<A HREF="
     cwg_defects.html#1069">1069</A>,
<A HREF="
     cwg_defects.html#1070">1070</A>,
<A HREF="
     cwg_defects.html#1071">1071</A>,
<A HREF="
     cwg_defects.html#1072">1072</A>,
<A HREF="
     cwg_defects.html#1073">1073</A>,
<A HREF="
     cwg_defects.html#1074">1074</A>,
<A HREF="
     cwg_defects.html#1075">1075</A>,
<A HREF="
     cwg_active.html#1076">1076</A>,
<A HREF="
     cwg_closed.html#1077">1077</A>,
<A HREF="
     cwg_closed.html#1078">1078</A>,
<A HREF="
     cwg_defects.html#1079">1079</A>,
<A HREF="
     cwg_defects.html#1080">1080</A>,
<A HREF="
     cwg_defects.html#1081">1081</A>,
<A HREF="
     cwg_defects.html#1082">1082</A>,
<A HREF="
     cwg_defects.html#1083">1083</A>,
<A HREF="
     cwg_closed.html#1084">1084</A>,
<A HREF="
     cwg_closed.html#1085">1085</A>,
<A HREF="
     cwg_defects.html#1086">1086</A>,
<A HREF="
     cwg_defects.html#1087">1087</A>,
<A HREF="
     cwg_defects.html#1088">1088</A>,
<A HREF="
     cwg_active.html#1089">1089</A>, and
<A HREF="
     cwg_defects.html#1090">1090</A>.
</LI>

<LI><B>Revision 70, 2010-08-06:</B> Reflected results of between-meetings
teleconference, including moving a number of issues to "tentatively ready"
status, updating proposed resolutions, and moving issues
<A HREF="
     cwg_defects.html#341">341</A>,
<A HREF="
     cwg_defects.html#355">355</A>,
<A HREF="
     cwg_active.html#472">472</A>, and
<A HREF="
     cwg_active.html#529">529</A> to "drafting" status for more work.
Changed <A HREF="
     cwg_defects.html#979">issue 979</A> to "CD2" status, which
was overlooked in the results of the March, 2010 meeting.  Closed issues
<A HREF="
     cwg_closed.html#1041">1041</A>, <A HREF="
     cwg_closed.html#1019">1019</A>, and
<A HREF="
     cwg_closed.html#507">507</A> as duplicates of issues
<A HREF="
     cwg_defects.html#924">924</A>, <A HREF="
     cwg_active.html#314">314</A>, and
<A HREF="
     cwg_active.html#260">260</A>, respectively.
</LI>

<LI><B>Revision 69, 2010-03-29:</B> Reflected deliberations at the March,
2010 (Pittsburgh, PA) meeting.  Placed all issues with "WP" status and
newly-approved "DR" issues into "CD2" status, to reflect advancing the
Final Committee Draft for balloting. Added new issues
<A HREF="
     cwg_active.html#1001">1001</A>,
<A HREF="
     cwg_closed.html#1002">1002</A>,
<A HREF="
     cwg_defects.html#1003">1003</A>,
<A HREF="
     cwg_defects.html#1004">1004</A>,
<A HREF="
     cwg_closed.html#1005">1005</A>,
<A HREF="
     cwg_defects.html#1006">1006</A>,
<A HREF="
     cwg_closed.html#1007">1007</A>,
<A HREF="
     cwg_closed.html#1008">1008</A>,
<A HREF="
     cwg_defects.html#1009">1009</A>,
<A HREF="
     cwg_defects.html#1010">1010</A>,
<A HREF="
     cwg_defects.html#1011">1011</A>,
<A HREF="
     cwg_defects.html#1012">1012</A>,
<A HREF="
     cwg_defects.html#1013">1013</A>,
<A HREF="
     cwg_closed.html#1014">1014</A>,
<A HREF="
     cwg_defects.html#1015">1015</A>,
<A HREF="
     cwg_defects.html#1016">1016</A>,
<A HREF="
     cwg_defects.html#1017">1017</A>,
<A HREF="
     cwg_defects.html#1018">1018</A>,
<A HREF="
     cwg_closed.html#1019">1019</A>,
<A HREF="
     cwg_defects.html#1020">1020</A>,
<A HREF="
     cwg_active.html#1021">1021</A>,
<A HREF="
     cwg_defects.html#1022">1022</A>,
<A HREF="
     cwg_closed.html#1023">1023</A>,
<A HREF="
     cwg_defects.html#1024">1024</A>,
<A HREF="
     cwg_defects.html#1025">1025</A>,
<A HREF="
     cwg_closed.html#1026">1026</A>,
<A HREF="
     cwg_active.html#1027">1027</A>,
<A HREF="
     cwg_active.html#1028">1028</A>,
<A HREF="
     cwg_defects.html#1029">1029</A>,
<A HREF="
     cwg_defects.html#1030">1030</A>,
<A HREF="
     cwg_defects.html#1031">1031</A>,
<A HREF="
     cwg_defects.html#1032">1032</A>,
<A HREF="
     cwg_defects.html#1033">1033</A>,
<A HREF="
     cwg_defects.html#1034">1034</A>,
<A HREF="
     cwg_defects.html#1035">1035</A>,
<A HREF="
     cwg_defects.html#1036">1036</A>,
<A HREF="
     cwg_defects.html#1037">1037</A>,
<A HREF="
     cwg_active.html#1038">1038</A>,
<A HREF="
     cwg_closed.html#1039">1039</A>,
<A HREF="
     cwg_closed.html#1040">1040</A>,
<A HREF="
     cwg_closed.html#1041">1041</A>,
<A HREF="
     cwg_defects.html#1042">1042</A>,
<A HREF="
     cwg_defects.html#1043">1043</A>,
<A HREF="
     cwg_defects.html#1044">1044</A>,
<A HREF="
     cwg_closed.html#1045">1045</A>,
<A HREF="
     cwg_active.html#1046">1046</A>,
<A HREF="
     cwg_defects.html#1047">1047</A>,
<A HREF="
     cwg_closed.html#1048">1048</A>,
<A HREF="
     cwg_active.html#1049">1049</A>,
<A HREF="
     cwg_closed.html#1050">1050</A>,
<A HREF="
     cwg_defects.html#1051">1051</A>,
<A HREF="
     cwg_closed.html#1052">1052</A>,
<A HREF="
     cwg_closed.html#1053">1053</A>,
<A HREF="
     cwg_defects.html#1054">1054</A>,
<A HREF="
     cwg_defects.html#1055">1055</A>,
<A HREF="
     cwg_defects.html#1056">1056</A>,
<A HREF="
     cwg_defects.html#1057">1057</A>,
<A HREF="
     cwg_closed.html#1058">1058</A>,
<A HREF="
     cwg_defects.html#1059">1059</A>,
<A HREF="
     cwg_defects.html#1060">1060</A>,
<A HREF="
     cwg_defects.html#1061">1061</A>,
<A HREF="
     cwg_defects.html#1062">1062</A>,
<A HREF="
     cwg_defects.html#1063">1063</A>,
<A HREF="
     cwg_defects.html#1064">1064</A>,
<A HREF="
     cwg_defects.html#1065">1065</A>,
<A HREF="
     cwg_defects.html#1066">1066</A>,
<A HREF="
     cwg_closed.html#1067">1067</A>, and
<A HREF="
     cwg_defects.html#1068">1068</A>.
</LI>

<LI><B>Revision 68, 2010-02-16:</B> Reflected results of between-meeting
teleconferences, including moving many issues to "tentatively ready" status
and incorporating draft proposed resolutions for many others.  Added
new issues <A HREF="
     cwg_defects.html#999">999</A> and <A HREF="
     cwg_defects.html#1000">1000</A>.
</LI>

<LI><B>Revision 67, 2009-11-08:</B> Reflected deliberations at the October,
2009 (Santa Cruz, CA) meeting. Added new issues
<A HREF="
     cwg_defects.html#972">972</A>,
<A HREF="
     cwg_defects.html#973">973</A>,
<A HREF="
     cwg_defects.html#974">974</A>,
<A HREF="
     cwg_defects.html#975">975</A>,
<A HREF="
     cwg_defects.html#976">976</A>,
<A HREF="
     cwg_defects.html#977">977</A>,
<A HREF="
     cwg_defects.html#978">978</A>,
<A HREF="
     cwg_defects.html#979">979</A>,
<A HREF="
     cwg_defects.html#980">980</A>,
<A HREF="
     cwg_defects.html#981">981</A>,
<A HREF="
     cwg_closed.html#982">982</A>,
<A HREF="
     cwg_defects.html#983">983</A>,
<A HREF="
     cwg_defects.html#984">984</A>,
<A HREF="
     cwg_defects.html#985">985</A>,
<A HREF="
     cwg_defects.html#986">986</A>,
<A HREF="
     cwg_active.html#987">987</A>,
<A HREF="
     cwg_defects.html#988">988</A>,
<A HREF="
     cwg_defects.html#989">989</A>,
<A HREF="
     cwg_defects.html#990">990</A>,
<A HREF="
     cwg_defects.html#991">991</A>,
<A HREF="
     cwg_closed.html#992">992</A>,
<A HREF="
     cwg_defects.html#993">993</A>,
<A HREF="
     cwg_defects.html#994">994</A>,
<A HREF="
     cwg_defects.html#995">995</A>,
<A HREF="
     cwg_defects.html#996">996</A>,
<A HREF="
     cwg_defects.html#997">997</A>, and
<A HREF="
     cwg_closed.html#998">998</A>.
</LI>

<LI><B>Revision 66, 2009-09-29:</B> Incorporated a new status,
"tentatively ready", for issues whose resolutions were reviewed and
approved by teleconference between meetings. Changed
<A HREF="
     cwg_defects.html#378">issue 378</A> to "CD1" status, as it was
resolved by the resolution of <A HREF="
     cwg_defects.html#276">issue 276</A>.
 Added new issues
<A HREF="
     cwg_active.html#949">949</A>,
<A HREF="
     cwg_defects.html#950">950</A>,
<A HREF="
     cwg_defects.html#951">951</A>,
<A HREF="
     cwg_active.html#952">952</A>,
<A HREF="
     cwg_defects.html#953">953</A>,
<A HREF="
     cwg_active.html#954">954</A>,
<A HREF="
     cwg_defects.html#955">955</A>,
<A HREF="
     cwg_defects.html#956">956</A>,
<A HREF="
     cwg_defects.html#957">957</A>,
<A HREF="
     cwg_closed.html#958">958</A>,
<A HREF="
     cwg_defects.html#959">959</A>,
<A HREF="
     cwg_defects.html#960">960</A>,
<A HREF="
     cwg_defects.html#961">961</A>,
<A HREF="
     cwg_defects.html#962">962</A>,
<A HREF="
     cwg_defects.html#963">963</A>,
<A HREF="
     cwg_defects.html#964">964</A>,
<A HREF="
     cwg_defects.html#965">965</A>,
<A HREF="
     cwg_defects.html#966">966</A>,
<A HREF="
     cwg_active.html#967">967</A>,
<A HREF="
     cwg_defects.html#968">968</A>,
<A HREF="
     cwg_defects.html#969">969</A>,
<A HREF="
     cwg_defects.html#970">970</A>, and
<A HREF="
     cwg_defects.html#971">971</A>.
</LI>

<LI><B>Revision 65, 2009-08-03:</B> Reflected deliberations from the
Frankfurt, Germany (July, 2009) meeting.  Added a new status,
"concepts," for issues related to the concepts proposal that was
removed from the working document and moved all concepts-related
issues to that status, effectively closing them.
 Changed the presentation of proposed
resolutions to use background colors in addition to font effects to
identify changes (i.e., <SPAN style="font-weight:bold;background-color:#A0FFA0">inserted</SPAN> and <SPAN style="text-decoration:line-through;background-color:#FFA0A0">deleted</SPAN>
text). Added new issues
<A HREF="
     cwg_defects.html#922">922</A>,
<A HREF="
     cwg_defects.html#923">923</A>,
<A HREF="
     cwg_defects.html#924">924</A>,
<A HREF="
     cwg_active.html#925">925</A>,
<A HREF="
     cwg_defects.html#926">926</A>,
<A HREF="
     cwg_defects.html#927">927</A>,
<A HREF="
     cwg_defects.html#928">928</A>,
<A HREF="
     cwg_defects.html#929">929</A>,
<A HREF="
     cwg_defects.html#930">930</A>,
<A HREF="
     cwg_defects.html#931">931</A>,
<A HREF="
     cwg_defects.html#932">932</A>,
<A HREF="
     cwg_defects.html#933">933</A>,
<A HREF="
     cwg_defects.html#934">934</A>,
<A HREF="
     cwg_defects.html#935">935</A>,
<A HREF="
     cwg_defects.html#936">936</A>,
<A HREF="
     cwg_closed.html#937">937</A>,
<A HREF="
     cwg_defects.html#938">938</A>,
<A HREF="
     cwg_defects.html#939">939</A>,
<A HREF="
     cwg_defects.html#940">940</A>,
<A HREF="
     cwg_defects.html#941">941</A>,
<A HREF="
     cwg_defects.html#942">942</A>,
<A HREF="
     cwg_active.html#943">943</A>,
<A HREF="
     cwg_active.html#944">944</A>,
<A HREF="
     cwg_defects.html#945">945</A>,
<A HREF="
     cwg_defects.html#946">946</A>,
<A HREF="
     cwg_closed.html#947">947</A>, and
<A HREF="
     cwg_defects.html#948">948</A>.
</LI>

<LI><B>Revision 64, 2009-06-19:</B> Fixed incorrect cross-references in
issues <A HREF="
     cwg_closed.html#867">867</A> and <A HREF="
     cwg_closed.html#868">868</A>.
Added proposed resolutions for issues
<A HREF="
     cwg_defects.html#527">527</A>,
<A HREF="
     cwg_defects.html#587">587</A>,
<A HREF="
     cwg_defects.html#589">589</A>,
<A HREF="
     cwg_defects.html#604">604</A>,
<A HREF="
     cwg_defects.html#719">719</A>,
<A HREF="
     cwg_defects.html#732">732</A>, and
<A HREF="
     cwg_defects.html#770">770</A>
and moved them to "review" status.  Added discussion to issues
<A HREF="
     cwg_defects.html#721">721</A>,
<A HREF="
     cwg_defects.html#760">760</A>,
<A HREF="
     cwg_closed.html#802">802</A>, and
<A HREF="
     cwg_defects.html#872">872</A>.  Added new issues
<A HREF="
     cwg_closed.html#889">889</A>,
<A HREF="
     cwg_closed.html#890">890</A>,
<A HREF="
     cwg_defects.html#891">891</A>,
<A HREF="
     cwg_defects.html#892">892</A>,
<A HREF="
     cwg_closed.html#893">893</A>,
<A HREF="
     cwg_closed.html#894">894</A>,
<A HREF="
     cwg_closed.html#895">895</A>,
<A HREF="
     cwg_defects.html#896">896</A>,
<A HREF="
     cwg_active.html#897">897</A>,
<A HREF="
     cwg_defects.html#898">898</A>,
<A HREF="
     cwg_defects.html#899">899</A>,
<A HREF="
     cwg_closed.html#900">900</A>,
<A HREF="
     cwg_active.html#901">901</A>,
<A HREF="
     cwg_closed.html#902">902</A>,
<A HREF="
     cwg_defects.html#903">903</A>,
<A HREF="
     cwg_defects.html#904">904</A>,
<A HREF="
     cwg_defects.html#905">905</A>,
<A HREF="
     cwg_defects.html#906">906</A>,
<A HREF="
     cwg_closed.html#907">907</A>,
<A HREF="
     cwg_defects.html#908">908</A>,
<A HREF="
     cwg_closed.html#909">909</A>,
<A HREF="
     cwg_defects.html#910">910</A>,
<A HREF="
     cwg_closed.html#911">911</A>,
<A HREF="
     cwg_defects.html#912">912</A>,
<A HREF="
     cwg_defects.html#913">913</A>,
<A HREF="
     cwg_closed.html#914">914</A>,
<A HREF="
     cwg_defects.html#915">915</A>,
<A HREF="
     cwg_active.html#916">916</A>,
<A HREF="
     cwg_closed.html#917">917</A>,
<A HREF="
     cwg_closed.html#918">918</A>,
<A HREF="
     cwg_defects.html#919">919</A>,
<A HREF="
     cwg_defects.html#920">920</A>, and
<A HREF="
     cwg_defects.html#921">921</A>.
</LI>

<LI><B>Revision 63, 2009-05-06:</B> Closed <A HREF="
     cwg_closed.html#839">issue 839</A> as a duplicate of <A HREF="
     cwg_defects.html#803">issue 803</A>.
Added notes to the discussion of issues <A HREF="
     cwg_active.html#325">325</A>,
<A HREF="
     cwg_defects.html#626">626</A>, <A HREF="
     cwg_defects.html#667">667</A>
<A HREF="
     cwg_defects.html#690">690</A>, <A HREF="
     cwg_defects.html#739">739</A>, and
<A HREF="
     cwg_closed.html#841">841</A>.  Moved <A HREF="
     cwg_closed.html#662">issue 662</A>
back to "open" status with additional discussion.  Added new issues
<A HREF="
     cwg_closed.html#843">843</A>,
<A HREF="
     cwg_closed.html#844">844</A>,
<A HREF="
     cwg_defects.html#845">845</A>,
<A HREF="
     cwg_defects.html#846">846</A>,
<A HREF="
     cwg_defects.html#847">847</A>,
<A HREF="
     cwg_closed.html#848">848</A>,
<A HREF="
     cwg_closed.html#849">849</A>,
<A HREF="
     cwg_defects.html#850">850</A>,
<A HREF="
     cwg_closed.html#851">851</A>,
<A HREF="
     cwg_active.html#852">852</A>,
<A HREF="
     cwg_defects.html#853">853</A>,
<A HREF="
     cwg_defects.html#854">854</A>,
<A HREF="
     cwg_defects.html#855">855</A>,
<A HREF="
     cwg_closed.html#856">856</A>,
<A HREF="
     cwg_closed.html#857">857</A>,
<A HREF="
     cwg_defects.html#858">858</A>,
<A HREF="
     cwg_closed.html#859">859</A>,
<A HREF="
     cwg_defects.html#860">860</A>,
<A HREF="
     cwg_defects.html#861">861</A>,
<A HREF="
     cwg_defects.html#862">862</A>,
<A HREF="
     cwg_defects.html#863">863</A>,
<A HREF="
     cwg_defects.html#864">864</A>,
<A HREF="
     cwg_defects.html#865">865</A>,
<A HREF="
     cwg_closed.html#866">866</A>,
<A HREF="
     cwg_closed.html#867">867</A>,
<A HREF="
     cwg_closed.html#868">868</A>,
<A HREF="
     cwg_defects.html#869">869</A>,
<A HREF="
     cwg_closed.html#870">870</A>,
<A HREF="
     cwg_closed.html#871">871</A>,
<A HREF="
     cwg_defects.html#872">872</A>,
<A HREF="
     cwg_defects.html#873">873</A>,
<A HREF="
     cwg_defects.html#874">874</A>,
<A HREF="
     cwg_closed.html#875">875</A>,
<A HREF="
     cwg_defects.html#876">876</A>,
<A HREF="
     cwg_defects.html#877">877</A>,
<A HREF="
     cwg_closed.html#878">878</A>,
<A HREF="
     cwg_defects.html#879">879</A>,
<A HREF="
     cwg_defects.html#880">880</A>,
<A HREF="
     cwg_closed.html#881">881</A>,
<A HREF="
     cwg_defects.html#882">882</A>,
<A HREF="
     cwg_defects.html#883">883</A>,
<A HREF="
     cwg_defects.html#884">884</A>,
<A HREF="
     cwg_closed.html#885">885</A>,
<A HREF="
     cwg_defects.html#886">886</A>,
<A HREF="
     cwg_defects.html#887">887</A>, and
<A HREF="
     cwg_defects.html#888">888</A>.
</LI>

<LI><B>Revision 62, 2009-03-23:</B> Reflected deliberations from the
Summit, NJ (March, 2009) meeting. Marked issues directly related to
National Body comments on the 2008-10 Committee Draft with a tag
identifying the relevant comment; the tag is both printed in the issue
body and reflected in the "Index by Status" document.  Added new
issues
<A HREF="
     cwg_defects.html#767">767</A>,
<A HREF="
     cwg_defects.html#768">768</A>,
<A HREF="
     cwg_defects.html#769">769</A>,
<A HREF="
     cwg_defects.html#770">770</A>,
<A HREF="
     cwg_defects.html#771">771</A>,
<A HREF="
     cwg_defects.html#772">772</A>,
<A HREF="
     cwg_defects.html#773">773</A>,
<A HREF="
     cwg_defects.html#774">774</A>,
<A HREF="
     cwg_defects.html#775">775</A>,
<A HREF="
     cwg_defects.html#776">776</A>,
<A HREF="
     cwg_defects.html#777">777</A>,
<A HREF="
     cwg_defects.html#778">778</A>,
<A HREF="
     cwg_defects.html#779">779</A>,
<A HREF="
     cwg_closed.html#780">780</A>,
<A HREF="
     cwg_closed.html#781">781</A>,
<A HREF="
     cwg_defects.html#782">782</A>,
<A HREF="
     cwg_active.html#783">783</A>,
<A HREF="
     cwg_defects.html#784">784</A>,
<A HREF="
     cwg_defects.html#785">785</A>,
<A HREF="
     cwg_defects.html#786">786</A>,
<A HREF="
     cwg_defects.html#787">787</A>,
<A HREF="
     cwg_defects.html#788">788</A>,
<A HREF="
     cwg_defects.html#789">789</A>,
<A HREF="
     cwg_defects.html#790">790</A>,
<A HREF="
     cwg_closed.html#791">791</A>,
<A HREF="
     cwg_defects.html#792">792</A>,
<A HREF="
     cwg_defects.html#793">793</A>,
<A HREF="
     cwg_closed.html#794">794</A>,
<A HREF="
     cwg_closed.html#795">795</A>,
<A HREF="
     cwg_defects.html#796">796</A>,
<A HREF="
     cwg_defects.html#797">797</A>,
<A HREF="
     cwg_defects.html#798">798</A>,
<A HREF="
     cwg_defects.html#799">799</A>,
<A HREF="
     cwg_closed.html#800">800</A>,
<A HREF="
     cwg_defects.html#801">801</A>,
<A HREF="
     cwg_closed.html#802">802</A>,
<A HREF="
     cwg_defects.html#803">803</A>,
<A HREF="
     cwg_defects.html#804">804</A>,
<A HREF="
     cwg_defects.html#805">805</A>,
<A HREF="
     cwg_defects.html#806">806</A>,
<A HREF="
     cwg_closed.html#807">807</A>,
<A HREF="
     cwg_defects.html#808">808</A>,
<A HREF="
     cwg_defects.html#809">809</A>,
<A HREF="
     cwg_defects.html#810">810</A>,
<A HREF="
     cwg_defects.html#811">811</A>,
<A HREF="
     cwg_defects.html#812">812</A>,
<A HREF="
     cwg_active.html#813">813</A>,
<A HREF="
     cwg_defects.html#814">814</A>,
<A HREF="
     cwg_defects.html#815">815</A>,
<A HREF="
     cwg_defects.html#816">816</A>,
<A HREF="
     cwg_defects.html#817">817</A>,
<A HREF="
     cwg_defects.html#818">818</A>,
<A HREF="
     cwg_closed.html#819">819</A>,
<A HREF="
     cwg_defects.html#820">820</A>,
<A HREF="
     cwg_closed.html#821">821</A>,
<A HREF="
     cwg_closed.html#822">822</A>,
<A HREF="
     cwg_defects.html#823">823</A>,
<A HREF="
     cwg_closed.html#824">824</A>,
<A HREF="
     cwg_closed.html#825">825</A>,
<A HREF="
     cwg_closed.html#826">826</A>,
<A HREF="
     cwg_closed.html#827">827</A>,
<A HREF="
     cwg_defects.html#828">828</A>,
<A HREF="
     cwg_closed.html#829">829</A>,
<A HREF="
     cwg_defects.html#830">830</A>,
<A HREF="
     cwg_defects.html#831">831</A>,
<A HREF="
     cwg_defects.html#832">832</A>,
<A HREF="
     cwg_defects.html#833">833</A>,
<A HREF="
     cwg_defects.html#834">834</A>,
<A HREF="
     cwg_defects.html#835">835</A>,
<A HREF="
     cwg_closed.html#836">836</A>,
<A HREF="
     cwg_defects.html#837">837</A>,
<A HREF="
     cwg_defects.html#838">838</A>,
<A HREF="
     cwg_closed.html#839">839</A>,
<A HREF="
     cwg_defects.html#840">840</A>,
<A HREF="
     cwg_closed.html#841">841</A>, and
<A HREF="
     cwg_defects.html#842">842</A>.
</LI>

<LI><B>Revision 61, 2009-02-08:</B> Provided a reference to a paper
containing a proposed resolution for issues <A HREF="
     cwg_defects.html#695">695</A>
and <A HREF="
     cwg_defects.html#699">699</A> and moved them to "review" status.
Added new issues
<A HREF="
     cwg_defects.html#749">749</A>,
<A HREF="
     cwg_defects.html#750">750</A>,
<A HREF="
     cwg_defects.html#751">751</A>,
<A HREF="
     cwg_defects.html#752">752</A>,
<A HREF="
     cwg_defects.html#753">753</A>,
<A HREF="
     cwg_defects.html#754">754</A>,
<A HREF="
     cwg_closed.html#755">755</A>,
<A HREF="
     cwg_defects.html#756">756</A>,
<A HREF="
     cwg_defects.html#757">757</A>,
<A HREF="
     cwg_defects.html#758">758</A>,
<A HREF="
     cwg_defects.html#759">759</A>,
<A HREF="
     cwg_defects.html#760">760</A>,
<A HREF="
     cwg_defects.html#761">761</A>,
<A HREF="
     cwg_defects.html#762">762</A>,
<A HREF="
     cwg_defects.html#763">763</A>,
<A HREF="
     cwg_defects.html#764">764</A>,
<A HREF="
     cwg_defects.html#765">765</A>, and
<A HREF="
     cwg_defects.html#766">766</A>.
</LI>

<LI><B>Revision 60, 2008-12-09:</B> Revised the resolution of
<A HREF="
     cwg_defects.html#653">issue 653</A> and moved to "review" status.
Added new issues
<A HREF="
     cwg_closed.html#724">724</A>,
<A HREF="
     cwg_closed.html#725">725</A>,
<A HREF="
     cwg_defects.html#726">726</A>,
<A HREF="
     cwg_active.html#727">727</A>,
<A HREF="
     cwg_closed.html#728">728</A>,
<A HREF="
     cwg_defects.html#729">729</A>,
<A HREF="
     cwg_defects.html#730">730</A>,
<A HREF="
     cwg_defects.html#731">731</A>,
<A HREF="
     cwg_defects.html#732">732</A>,
<A HREF="
     cwg_closed.html#733">733</A>,
<A HREF="
     cwg_defects.html#734">734</A>,
<A HREF="
     cwg_defects.html#735">735</A>,
<A HREF="
     cwg_closed.html#736">736</A>,
<A HREF="
     cwg_defects.html#737">737</A>,
<A HREF="
     cwg_defects.html#738">738</A>,
<A HREF="
     cwg_defects.html#739">739</A>,
<A HREF="
     cwg_defects.html#740">740</A>,
<A HREF="
     cwg_defects.html#741">741</A>,
<A HREF="
     cwg_active.html#742">742</A>,
<A HREF="
     cwg_defects.html#743">743</A>,
<A HREF="
     cwg_defects.html#744">744</A>,
<A HREF="
     cwg_active.html#745">745</A>,
<A HREF="
     cwg_defects.html#746">746</A>,
<A HREF="
     cwg_closed.html#747">747</A>, and
<A HREF="
     cwg_closed.html#748">748</A>.
</LI>

<LI><B>Revision 59, 2008-10-05:</B> Reflected deliberations from the
San Francisco (September, 2008) meeting. Placed all issues with
"WP" status and newly-approved "DR" issues into "CD1" status, to
reflect advancing the Committee Draft for balloting.  Added new
proposed resolutions to issues <A HREF="
     cwg_defects.html#696">696</A>,
<A HREF="
     cwg_defects.html#704">704</A>, and <A HREF="
     cwg_defects.html#705">705</A>
and moved them to "review" status. Changed
<A HREF="
     cwg_closed.html#265">issue 265</A> to "dup" status in favor of
<A HREF="
     cwg_defects.html#353">issue 353</A>, which was approved in 2003.
Added new issues
<A HREF="
     cwg_defects.html#710">710</A>,
<A HREF="
     cwg_defects.html#711">711</A>,
<A HREF="
     cwg_defects.html#712">712</A>,
<A HREF="
     cwg_defects.html#713">713</A>,
<A HREF="
     cwg_defects.html#714">714</A>,
<A HREF="
     cwg_defects.html#715">715</A>,
<A HREF="
     cwg_defects.html#716">716</A>,
<A HREF="
     cwg_defects.html#717">717</A>,
<A HREF="
     cwg_active.html#718">718</A>,
<A HREF="
     cwg_defects.html#719">719</A>,
<A HREF="
     cwg_defects.html#720">720</A>,
<A HREF="
     cwg_defects.html#721">721</A>,
<A HREF="
     cwg_defects.html#722">722</A>, and
<A HREF="
     cwg_closed.html#723">723</A>.
</LI>

<LI><B>Revision 58, 2008-08-25:</B> Fixed some incorrect section
references.  Fixed the title of <A HREF="
     cwg_defects.html#692">issue 692</A>.
Changed the status of <A HREF="
     cwg_defects.html#603">issue 603</A> to "WP",
as the paper that resolved it was approved in April, 2007.  Moved
<A HREF="
     cwg_defects.html#657">issue 657</A> back to "review" status and
added proposed wording. Added discussion to issues
<A HREF="
     cwg_defects.html#693">693</A> and <A HREF="
     cwg_active.html#697">697</A>.
Added or revised resolutions for issues
<A HREF="
     cwg_defects.html#606">606</A>,
<A HREF="
     cwg_defects.html#614">614</A>,
<A HREF="
     cwg_defects.html#652">652</A>,
<A HREF="
     cwg_defects.html#685">685</A>, and
<A HREF="
     cwg_defects.html#694">694</A> and moved them to "review" status.
Added new issues
<A HREF="
     cwg_defects.html#704">704</A>,
<A HREF="
     cwg_defects.html#705">705</A>,
<A HREF="
     cwg_closed.html#706">706</A>,
<A HREF="
     cwg_defects.html#707">707</A>,
<A HREF="
     cwg_active.html#708">708</A>, and
<A HREF="
     cwg_defects.html#709">709</A>.
</LI>

<LI><B>Revision 57, 2008-07-27:</B>  Updated the status of issues
<A HREF="
     cwg_defects.html#222">222</A>, <A HREF="
     cwg_defects.html#309">309</A>, and
<A HREF="
     cwg_defects.html#632">632</A> to reflect actions at the June, 2008
meeting that were inadvertently omitted in the preceding revision.
Added proposed wording for
<A HREF="
     cwg_defects.html#683">issue 683</A> and moved it to "review" status.
Added new issues
<A HREF="
     cwg_active.html#697">697</A>,
<A HREF="
     cwg_active.html#698">698</A>,
<A HREF="
     cwg_defects.html#699">699</A>,
<A HREF="
     cwg_defects.html#700">700</A>,
<A HREF="
     cwg_defects.html#701">701</A>,
<A HREF="
     cwg_defects.html#702">702</A>, and
<A HREF="
     cwg_defects.html#703">703</A>.
</LI>

<LI><B>Revision 56, 2008-06-29:</B> Reflected deliberations from the
Sophia Antipolis (June, 2008) meeting.  Added discussion to issues
<A HREF="
     cwg_closed.html#507">507</A> and
<A HREF="
     cwg_defects.html#527">527</A>. Added proposed resolution for
<A HREF="
     cwg_defects.html#653">issue 653</A>.  Added new issues
<A HREF="
     cwg_defects.html#695">695</A> and <A HREF="
     cwg_defects.html#696">696</A>.
</LI>

<LI><B>Revision 55, 2008-05-18:</B> Added proposed resolutions for
issues
<A HREF="
     cwg_defects.html#220">220</A>,
<A HREF="
     cwg_defects.html#257">257</A>,
<A HREF="
     cwg_defects.html#292">292</A>,
<A HREF="
     cwg_defects.html#341">341</A>,
<A HREF="
     cwg_defects.html#539">539</A>,
<A HREF="
     cwg_active.html#554">554</A>,
<A HREF="
     cwg_defects.html#570">570</A>,
<A HREF="
     cwg_defects.html#571">571</A>,
<A HREF="
     cwg_defects.html#576">576</A>,
<A HREF="
     cwg_defects.html#597">597</A>,
<A HREF="
     cwg_defects.html#621">621</A>,
<A HREF="
     cwg_defects.html#624">624</A>,
<A HREF="
     cwg_defects.html#626">626</A>,
<A HREF="
     cwg_defects.html#633">633</A>,
<A HREF="
     cwg_defects.html#634">634</A>,
<A HREF="
     cwg_defects.html#639">639</A>, and
<A HREF="
     cwg_defects.html#642">642</A>,
and moved them to "review" status.
Moved <A HREF="
     cwg_closed.html#155">issue 155</A> to "dup" status in
favor of <A HREF="
     cwg_defects.html#632">issue 632</A>, which was changed
to "review" status in light of its connection with the
initializer-list proposal.  Moved issues <A HREF="
     cwg_defects.html#530">530</A>
and <A HREF="
     cwg_defects.html#551">551</A>
to "WP" status because they were resolved by the constexpr proposal.
Moved <A HREF="
     cwg_closed.html#646">issue 646</A> to "review" status because
it appears to be "NAD".  Changed <A HREF="
     cwg_defects.html#240">issue 240</A>
to "review" status (from "ready") in light of input from WG14 regarding
a similar issue.  Added new issues
<A HREF="
     cwg_defects.html#685">685</A>,
<A HREF="
     cwg_defects.html#686">686</A>,
<A HREF="
     cwg_closed.html#687">687</A>,
<A HREF="
     cwg_defects.html#688">688</A>,
<A HREF="
     cwg_active.html#689">689</A>,
<A HREF="
     cwg_defects.html#690">690</A>,
<A HREF="
     cwg_defects.html#691">691</A>,
<A HREF="
     cwg_defects.html#692">692</A>,
<A HREF="
     cwg_defects.html#693">693</A>, and
<A HREF="
     cwg_defects.html#694">694</A>.
</LI>

<LI><B>Revision 54, 2008-03-17:</B> Reflected deliberations from the
Bellevue (February, 2008) meeting.  Restructured references inside
&#8220;definitions&#8221; sections (1.3 [intro.defs],
17.3 [definitions]) because the individual definitions are not
sections.  Returned <A HREF="
     cwg_closed.html#646">issue 646</A> to "open"
status (it was previously erroneously in "drafting" status).  Moved
issues <A HREF="
     cwg_closed.html#347">347</A>, <A HREF="
     cwg_closed.html#512">512</A>,
and <A HREF="
     cwg_closed.html#236">236</A> to "review" status with a
recommendation to close them as "NAD."  Changed issues <A HREF="
     cwg_defects.html#220">220</A> and <A HREF="
     cwg_defects.html#256">256</A> back to "open"
status  and
annotated them to indicate that they have been accepted by EWG and
referred to CWG for action for C++0x.  Changed issues <A HREF="
     cwg_active.html#6">6</A> and <A HREF="
     cwg_active.html#150">150</A> back to "open"
status  and
annotated them to indicate that they have been accepted by EWG and
referred to CWG for action, but not for C++0x. Closed issues
<A HREF="
     cwg_closed.html#107">107</A>,
<A HREF="
     cwg_closed.html#168">168</A>,
<A HREF="
     cwg_closed.html#229">229</A>,
<A HREF="
     cwg_closed.html#294">294</A>, and
<A HREF="
     cwg_closed.html#359">359</A> as "NAD" to reflect the recommendation
of EWG.  Added new issues
<A HREF="
     cwg_closed.html#673">673</A>,
<A HREF="
     cwg_defects.html#674">674</A>,
<A HREF="
     cwg_defects.html#675">675</A>,
<A HREF="
     cwg_defects.html#676">676</A>,
<A HREF="
     cwg_defects.html#677">677</A>,
<A HREF="
     cwg_defects.html#678">678</A>,
<A HREF="
     cwg_defects.html#679">679</A>,
<A HREF="
     cwg_defects.html#680">680</A>,
<A HREF="
     cwg_defects.html#681">681</A>,
<A HREF="
     cwg_active.html#682">682</A>,
<A HREF="
     cwg_defects.html#683">683</A>, and
<A HREF="
     cwg_defects.html#684">684</A>.
</LI>

<LI><B>Revision 53, 2008-02-03:</B>
Updated the proposed resolutions for issues <A HREF="
     cwg_defects.html#288">288</A>
and <A HREF="
     cwg_defects.html#342">342</A>.  Updated the status of issues
<A HREF="
     cwg_defects.html#199">199</A> and <A HREF="
     cwg_defects.html#430">430</A> to reflect
actions at the Oxford (April, 2007) meeting.
Added proposed resolutions and
changed the status to "review" for issues
<A HREF="
     cwg_defects.html#28">28</A>,
<A HREF="
     cwg_closed.html#111">111</A>,
<A HREF="
     cwg_defects.html#118">118</A>,
<A HREF="
     cwg_defects.html#141">141</A>,
<A HREF="
     cwg_defects.html#240">240</A>,
<A HREF="
     cwg_defects.html#276">276</A>,
<A HREF="
     cwg_defects.html#309">309</A>,
<A HREF="
     cwg_defects.html#355">355</A>,
<A HREF="
     cwg_defects.html#373">373</A>,
<A HREF="
     cwg_defects.html#378">378</A>,
<A HREF="
     cwg_defects.html#462">462</A>,
<A HREF="
     cwg_defects.html#485">485</A>,
<A HREF="
     cwg_defects.html#535">535</A>,
<A HREF="
     cwg_closed.html#574">574</A>,
<A HREF="
     cwg_defects.html#601">601</A>,
<A HREF="
     cwg_defects.html#608">608</A>,
<A HREF="
     cwg_defects.html#641">641</A>,
<A HREF="
     cwg_defects.html#645">645</A>, and
<A HREF="
     cwg_defects.html#651">651</A>.
Added new issues
<A HREF="
     cwg_defects.html#667">667</A>,
<A HREF="
     cwg_defects.html#668">668</A>,
<A HREF="
     cwg_closed.html#669">669</A>,
<A HREF="
     cwg_active.html#670">670</A>,
<A HREF="
     cwg_defects.html#671">671</A>, and
<A HREF="
     cwg_defects.html#672">672</A>.
</LI>

<LI><B>Revision 52, 2007-12-09:</B>
Updated the status of issues <A HREF="
     cwg_defects.html#568">568</A> and
<A HREF="
     cwg_defects.html#620">620</A> to reflect actions at the Toronto
(July, 2007) meeting. Fixed a typographical error in the example for
<A HREF="
     cwg_defects.html#606">issue 606</A>.
Added new issues
<A HREF="
     cwg_defects.html#654">654</A>,
<A HREF="
     cwg_defects.html#655">655</A>,
<A HREF="
     cwg_defects.html#656">656</A>,
<A HREF="
     cwg_defects.html#657">657</A>,
<A HREF="
     cwg_defects.html#658">658</A>,
<A HREF="
     cwg_defects.html#659">659</A>,
<A HREF="
     cwg_defects.html#660">660</A>,
<A HREF="
     cwg_defects.html#661">661</A>,
<A HREF="
     cwg_closed.html#662">662</A>,
<A HREF="
     cwg_defects.html#663">663</A>,
<A HREF="
     cwg_defects.html#664">664</A>,
<A HREF="
     cwg_defects.html#665">665</A>, and
<A HREF="
     cwg_defects.html#666">666</A>.
</LI>

<LI><B>Revision 51, 2007-10-09:</B> Reflected deliberations from the Kona
(October, 2007) meeting.  Added new issues
<A HREF="
     cwg_defects.html#652">652</A> and <A HREF="
     cwg_defects.html#653">653</A>.
</LI>

<LI><B>Revision 50, 2007-09-09:</B> Updated section reference numbers to use
the numbering of the most recent working draft and added text identifying
the document number of that draft at the beginning of each issues
list document.  Updated <A HREF="
     cwg_defects.html#475">issue 475</A>
with discussion regarding the point at which
<TT>std::uncaught_exception()</TT> becomes <TT>false</TT>.  Added new issues
<A HREF="
     cwg_defects.html#642">642</A>,
<A HREF="
     cwg_closed.html#643">643</A>,
<A HREF="
     cwg_defects.html#644">644</A>,
<A HREF="
     cwg_defects.html#645">645</A>,
<A HREF="
     cwg_closed.html#646">646</A>,
<A HREF="
     cwg_defects.html#647">647</A>,
<A HREF="
     cwg_defects.html#648">648</A>,
<A HREF="
     cwg_defects.html#649">649</A>,
<A HREF="
     cwg_defects.html#650">650</A>, and
<A HREF="
     cwg_defects.html#651">651</A>.
</LI>

<LI><B>Revision 49, 2007-08-05:</B> Reflected deliberations from the
Toronto (July, 2007) meeting.  Added additional discussion to issues
<A HREF="
     cwg_closed.html#219">219</A> and <A HREF="
     cwg_defects.html#339">339</A>.
Added new issues
<A HREF="
     cwg_defects.html#637">637</A>,
<A HREF="
     cwg_defects.html#638">638</A>,
<A HREF="
     cwg_defects.html#639">639</A>,
<A HREF="
     cwg_active.html#640">640</A>, and
<A HREF="
     cwg_defects.html#641">641</A>.
</LI>

<LI><B>Revision 48, 2007-06-24:</B> Added new issues
<A HREF="
     cwg_defects.html#632">632</A>,
<A HREF="
     cwg_defects.html#633">633</A>,
<A HREF="
     cwg_defects.html#634">634</A>,
<A HREF="
     cwg_closed.html#635">635</A>, and
<A HREF="
     cwg_active.html#636">636</A>.
</LI>

<LI><B>Revision 47, 2007-05-06:</B> Reflected deliberations from the
Oxford (April, 2007) meeting.
Added new issues
<A HREF="
     cwg_defects.html#626">626</A>,
<A HREF="
     cwg_closed.html#627">627</A>,
<A HREF="
     cwg_defects.html#628">628</A>,
<A HREF="
     cwg_defects.html#629">629</A>,
<A HREF="
     cwg_defects.html#630">630</A>, and
<A HREF="
     cwg_defects.html#631">631</A>.
</LI>

<LI><B>Revision 46, 2007-03-11:</B> Added proposed wording to
<A HREF="
     cwg_defects.html#495">issue 495</A> and moved it to
&#8220;review&#8221; status.  Added new issues
<A HREF="
     cwg_defects.html#612">612</A>,
<A HREF="
     cwg_defects.html#613">613</A>,
<A HREF="
     cwg_defects.html#614">614</A>,
<A HREF="
     cwg_defects.html#615">615</A>,
<A HREF="
     cwg_defects.html#616">616</A>,
<A HREF="
     cwg_active.html#617">617</A>,
<A HREF="
     cwg_defects.html#618">618</A>,
<A HREF="
     cwg_defects.html#619">619</A>,
<A HREF="
     cwg_defects.html#620">620</A>,
<A HREF="
     cwg_defects.html#621">621</A>,
<A HREF="
     cwg_closed.html#622">622</A>,
<A HREF="
     cwg_closed.html#623">623</A>,
<A HREF="
     cwg_defects.html#624">624</A>, and
<A HREF="
     cwg_defects.html#625">625</A>.
</LI>

<LI><B>Revision 45, 2007-01-14:</B> Changed the status of
<A HREF="
     cwg_defects.html#78">issue 78</A> from TC1 to WP.
Added new issues
<A HREF="
     cwg_defects.html#603">603</A>,
<A HREF="
     cwg_defects.html#604">604</A>,
<A HREF="
     cwg_defects.html#605">605</A>,
<A HREF="
     cwg_defects.html#606">606</A>,
<A HREF="
     cwg_active.html#607">607</A>,
<A HREF="
     cwg_defects.html#608">608</A>,
<A HREF="
     cwg_active.html#609">609</A>,
<A HREF="
     cwg_closed.html#610">610</A>, and
<A HREF="
     cwg_defects.html#611">611</A>.
</LI>

<LI><B>Revision 44, 2006-11-05:</B> Reflected deliberations from the
Portland (October, 2006) meeting.  Added proposed wording for issues
<A HREF="
     cwg_defects.html#288">288</A>,
<A HREF="
     cwg_defects.html#342">342</A>, and
<A HREF="
     cwg_defects.html#572">572</A>, and moved them to &#8220;review&#8221;
status.  Added new issues
<A HREF="
     cwg_active.html#596">596</A>,
<A HREF="
     cwg_defects.html#597">597</A>,
<A HREF="
     cwg_defects.html#598">598</A>,
<A HREF="
     cwg_defects.html#599">599</A>,
<A HREF="
     cwg_active.html#600">600</A>,
<A HREF="
     cwg_defects.html#601">601</A>, and
<A HREF="
     cwg_defects.html#602">602</A>.
</LI>

<LI><B>Revision 43, 2006-09-09:</B> Updated issues
<A HREF="
     cwg_defects.html#218">218</A>,
<A HREF="
     cwg_defects.html#357">357</A>, and
<A HREF="
     cwg_defects.html#537">537</A> with additional discussion and proposed
resolutions and moved them to &#8220;review&#8221; status; added issues
<A HREF="
     cwg_defects.html#589">589</A>,
<A HREF="
     cwg_defects.html#590">590</A>,
<A HREF="
     cwg_active.html#591">591</A>,
<A HREF="
     cwg_defects.html#592">592</A>,
<A HREF="
     cwg_closed.html#593">593</A>,
<A HREF="
     cwg_defects.html#594">594</A>, and
<A HREF="
     cwg_closed.html#595">595</A>.
</LI>

<LI><B>Revision 42, 2006-06-23:</B> Updated issues
<A HREF="
     cwg_defects.html#408">408</A> and <A HREF="
     cwg_defects.html#561">561</A> with
additional discussion; added a reference to a paper on the topic to
<A HREF="
     cwg_closed.html#567">issue 567</A>; and added issues
<A HREF="
     cwg_active.html#578">578</A>,
<A HREF="
     cwg_active.html#579">579</A>,
<A HREF="
     cwg_defects.html#580">580</A>,
<A HREF="
     cwg_active.html#581">581</A>,
<A HREF="
     cwg_defects.html#582">582</A>,
<A HREF="
     cwg_defects.html#583">583</A>,
<A HREF="
     cwg_closed.html#584">584</A>,
<A HREF="
     cwg_closed.html#585">585</A>,
<A HREF="
     cwg_closed.html#586">586</A>,
<A HREF="
     cwg_defects.html#587">587</A>, and
<A HREF="
     cwg_defects.html#588">588</A>.
</LI>

<LI><B>Revision 41, 2006-04-22:</B> Reflected deliberations from the
Berlin (April, 2006) meeting.  Added issues
<A HREF="
     cwg_active.html#562">562</A>,
<A HREF="
     cwg_active.html#563">563</A>,
<A HREF="
     cwg_defects.html#564">564</A>,
<A HREF="
     cwg_defects.html#565">565</A>,
<A HREF="
     cwg_closed.html#566">566</A>,
<A HREF="
     cwg_closed.html#567">567</A>,
<A HREF="
     cwg_defects.html#568">568</A>,
<A HREF="
     cwg_defects.html#569">569</A>,
<A HREF="
     cwg_defects.html#570">570</A>,
<A HREF="
     cwg_defects.html#571">571</A>,
<A HREF="
     cwg_defects.html#572">572</A>,
<A HREF="
     cwg_defects.html#573">573</A>,
<A HREF="
     cwg_closed.html#574">574</A>,
<A HREF="
     cwg_defects.html#575">575</A>,
<A HREF="
     cwg_defects.html#576">576</A>, and
<A HREF="
     cwg_defects.html#577">577</A>.
</LI>

<LI><B>Revision 40, 2006-02-24:</B> Updated
<A HREF="
     cwg_defects.html#540">issue 540</A> to refer to paper
J16/06-0022 = WG21 N1952 for its resolution.  Updated
<A HREF="
     cwg_active.html#453">issue 453</A> to note the need for additional
drafting.  Reopened <A HREF="
     cwg_active.html#504">issue 504</A> and broadened
its scope to include object declarations as well.  Updated
<A HREF="
     cwg_active.html#150">issue 150</A> (in &#8220;extension&#8221; status)
with additional commentary.
Added issues
<A HREF="
     cwg_closed.html#552">552</A>,
<A HREF="
     cwg_closed.html#553">553</A>,
<A HREF="
     cwg_active.html#554">554</A>,
<A HREF="
     cwg_active.html#555">555</A>,
<A HREF="
     cwg_defects.html#556">556</A>,
<A HREF="
     cwg_defects.html#557">557</A>,
<A HREF="
     cwg_defects.html#558">558</A>,
<A HREF="
     cwg_defects.html#559">559</A>,
<A HREF="
     cwg_active.html#560">560</A>, and
<A HREF="
     cwg_defects.html#561">561</A>.
</LI>

<LI><B>Revision 39, 2005-12-16:</B> Updated
<A HREF="
     cwg_defects.html#488">issue 488</A> with additional discussion.
Added issues
<A HREF="
     cwg_defects.html#538">538</A>,
<A HREF="
     cwg_defects.html#539">539</A>,
<A HREF="
     cwg_defects.html#540">540</A>,
<A HREF="
     cwg_defects.html#541">541</A>,
<A HREF="
     cwg_defects.html#542">542</A>,
<A HREF="
     cwg_defects.html#543">543</A>,
<A HREF="
     cwg_closed.html#544">544</A>,
<A HREF="
     cwg_active.html#545">545</A>,
<A HREF="
     cwg_defects.html#546">546</A>,
<A HREF="
     cwg_defects.html#547">547</A>,
<A HREF="
     cwg_closed.html#548">548</A>,
<A HREF="
     cwg_active.html#549">549</A>,
<A HREF="
     cwg_active.html#550">550</A>, and
<A HREF="
     cwg_defects.html#551">551</A>.
</LI>

<LI><B>Revision 38, 2005-10-22:</B> Reflected deliberations from the
Mont Tremblant (October, 2005) meeting.  Added isues
<A HREF="
     cwg_defects.html#530">530</A>,
<A HREF="
     cwg_defects.html#531">531</A>,
<A HREF="
     cwg_defects.html#532">532</A>,
<A HREF="
     cwg_closed.html#533">533</A>,
<A HREF="
     cwg_defects.html#534">534</A>,
<A HREF="
     cwg_defects.html#535">535</A>,
<A HREF="
     cwg_active.html#536">536</A>, and
<A HREF="
     cwg_defects.html#537">537</A>.
</LI>

<LI><B>Revision 37, 2005-08-27:</B> Added issues
<A HREF="
     cwg_active.html#523">523</A>,
<A HREF="
     cwg_defects.html#524">524</A>,
<A HREF="
     cwg_defects.html#525">525</A>,
<A HREF="
     cwg_defects.html#526">526</A>,
<A HREF="
     cwg_defects.html#527">527</A>,
<A HREF="
     cwg_active.html#528">528</A>, and
<A HREF="
     cwg_active.html#529">529</A>.
</LI>

<LI><B>Revision 36, 2005-06-27:</B> Reopened <A HREF="
     cwg_defects.html#484">issue 484</A> for additional discussion.
Added issues
<A HREF="
     cwg_defects.html#517">517</A>,
<A HREF="
     cwg_defects.html#518">518</A>,
<A HREF="
     cwg_defects.html#519">519</A>,
<A HREF="
     cwg_defects.html#520">520</A>,
<A HREF="
     cwg_defects.html#521">521</A>, and
<A HREF="
     cwg_defects.html#522">522</A>.
</LI>

<LI><B>Revision 35, 2005-05-01:</B> Reflected deliberations from
the Lillehammer (April, 2005) meeting.  Updated issues
<A HREF="
     cwg_active.html#189">189</A> and <A HREF="
     cwg_active.html#459">459</A> with additional
discussion.  Added new issues
<A HREF="
     cwg_active.html#504">504</A>,
<A HREF="
     cwg_defects.html#505">505</A>,
<A HREF="
     cwg_defects.html#506">506</A>,
<A HREF="
     cwg_closed.html#507">507</A>,
<A HREF="
     cwg_defects.html#508">508</A>,
<A HREF="
     cwg_defects.html#509">509</A>,
<A HREF="
     cwg_defects.html#510">510</A>,
<A HREF="
     cwg_active.html#511">511</A>,
<A HREF="
     cwg_closed.html#512">512</A>,
<A HREF="
     cwg_defects.html#513">513</A>,
<A HREF="
     cwg_defects.html#514">514</A>,
<A HREF="
     cwg_defects.html#515">515</A>, and
<A HREF="
     cwg_defects.html#516">516</A>.
</LI>

<LI><B>Revision 34: 2005-03-06:</B> Closed <A HREF="
     cwg_closed.html#471">issue 471</A> as NAD; updated issues
<A HREF="
     cwg_defects.html#58">58</A>,
<A HREF="
     cwg_active.html#232">232</A>,
<A HREF="
     cwg_defects.html#339">339</A>,
<A HREF="
     cwg_defects.html#407">407</A>, and
<A HREF="
     cwg_defects.html#494">494</A>
with additional discussion; and added new issues
<A HREF="
     cwg_active.html#498">498</A>,
<A HREF="
     cwg_defects.html#499">499</A>,
<A HREF="
     cwg_defects.html#500">500</A>,
<A HREF="
     cwg_closed.html#501">501</A>,
<A HREF="
     cwg_defects.html#502">502</A>, and
<A HREF="
     cwg_active.html#503">503</A>.
</LI>

<LI><B>Revision 33: 2005-01-14:</B> Updated <A HREF="
     cwg_active.html#36">issue 36</A> with additional discussion.  Added new
issues
<A HREF="
     cwg_defects.html#485">485</A>,
<A HREF="
     cwg_defects.html#486">486</A>,
<A HREF="
     cwg_closed.html#487">487</A>,
<A HREF="
     cwg_defects.html#488">488</A>,
<A HREF="
     cwg_closed.html#489">489</A>,
<A HREF="
     cwg_defects.html#490">490</A>,
<A HREF="
     cwg_defects.html#491">491</A>,
<A HREF="
     cwg_defects.html#492">492</A>,
<A HREF="
     cwg_defects.html#493">493</A>,
<A HREF="
     cwg_defects.html#494">494</A>,
<A HREF="
     cwg_defects.html#495">495</A>,
<A HREF="
     cwg_defects.html#496">496</A>, and
<A HREF="
     cwg_defects.html#497">497</A>.
</LI>

<LI><B>Revision 32: 2004-11-07:</B> Reflected deliberations from
the Redmond (October, 2004) meeting.  Added new issues
<A HREF="
     cwg_defects.html#475">475</A>,
<A HREF="
     cwg_closed.html#476">476</A>,
<A HREF="
     cwg_defects.html#477">477</A>,
<A HREF="
     cwg_closed.html#478">478</A>,
<A HREF="
     cwg_defects.html#479">479</A>,
<A HREF="
     cwg_defects.html#480">480</A>,
<A HREF="
     cwg_defects.html#481">481</A>,
<A HREF="
     cwg_defects.html#482">482</A>,
<A HREF="
     cwg_defects.html#483">483</A>, and
<A HREF="
     cwg_defects.html#484">484</A>.
</LI>

<LI>
<B>Revision 31: 2004-09-10:</B> Updated <A HREF="
     cwg_active.html#268">issue 268</A> with comments from WG14; added comments and changed
the status of <A HREF="
     cwg_defects.html#451">issue 451</A> back to
&#8220;open&#8221;; added discussion to issues
<A HREF="
     cwg_closed.html#334">334</A>,
<A HREF="
     cwg_defects.html#341">341</A>,
<A HREF="
     cwg_defects.html#385">385</A>,
<A HREF="
     cwg_active.html#399">399</A>, and
<A HREF="
     cwg_defects.html#430">430</A>;
and added new issues
<A HREF="
     cwg_defects.html#470">470</A>,
<A HREF="
     cwg_closed.html#471">471</A>,
<A HREF="
     cwg_active.html#472">472</A>,
<A HREF="
     cwg_active.html#473">473</A>, and
<A HREF="
     cwg_defects.html#474">474</A>.
</LI>

<LI>
<B>Revision 30: 2004-04-09:</B> Reflected deliberations from the
Sydney (March, 2004) meeting.  Added issues 461-469, updated issues
<A HREF="
     cwg_defects.html#39">39</A>,
<A HREF="
     cwg_defects.html#86">86</A>,
<A HREF="
     cwg_defects.html#257">257</A>,
<A HREF="
     cwg_defects.html#291">291</A>,
<A HREF="
     cwg_defects.html#391">391</A>,
<A HREF="
     cwg_defects.html#389">389</A>,
<A HREF="
     cwg_closed.html#435">435</A>,
<A HREF="
     cwg_defects.html#436">436</A>,
<A HREF="
     cwg_defects.html#437">437</A>,
<A HREF="
     cwg_defects.html#439">439</A>,
<A HREF="
     cwg_defects.html#441">441</A>,
<A HREF="
     cwg_defects.html#442">442</A>,
<A HREF="
     cwg_defects.html#446">446</A>,
<A HREF="
     cwg_defects.html#450">450</A>,
<A HREF="
     cwg_active.html#453">453</A>,
and
<A HREF="
     cwg_defects.html#458">458</A>.
</LI>

<LI>
<B>Revision 29: 2004-02-13:</B> Added issues 441-460, updated issues
<A HREF="
     cwg_defects.html#39">39</A>,
<A HREF="
     cwg_defects.html#291">291</A>,
<A HREF="
     cwg_defects.html#306">306</A>,
<A HREF="
     cwg_defects.html#319">319</A>,
<A HREF="
     cwg_defects.html#389">389</A>,
<A HREF="
     cwg_defects.html#394">394</A>,
<A HREF="
     cwg_defects.html#413">413</A>,
and
<A HREF="
     cwg_defects.html#417">417</A>.
</LI>

<LI>
<B>Revision 28: 2003-11-15:</B> Reflected deliberations from the
Kona (October, 2003) meeting.  Added issues 435-438.
</LI>

<LI>
<B>Revision 27: 2003-09-19:</B> Added new issues 412-434, updated
<A HREF="
     cwg_defects.html#54">issues 54</A>,
<A HREF="
     cwg_defects.html#301">301</A>,
<A HREF="
     cwg_defects.html#372">372</A>,
<A HREF="
     cwg_defects.html#382">382</A>,
<A HREF="
     cwg_defects.html#391">391</A>, and
<A HREF="
     cwg_active.html#399">399</A>.
</LI>

<LI>
<B>Revision 26: 2003-04-25:</B>  Reflected deliberations from
the Oxford (April, 2003) meeting.  Added new issues 402-411.
</LI>

<LI>
<B>Revision 25: 2003-03-03:</B> Added new issues 390-401, updated
<A HREF="
     cwg_defects.html#214">issue 214</A>.
</LI>
<LI>
<B>Revision 24: 2002-11-08:</B> Reflected deliberations from the
Santa Cruz (October, 2002) meeting.  Added new issues 379-389.
</LI>

<LI>
<B>Revision 23: 2002-09-10:</B> Added new issues 355-378, updated
<A HREF="
     cwg_defects.html#298">issue 298</A> and <A HREF="
     cwg_defects.html#214">issue 214</A>.
</LI>
<LI>
<B>Revision 22: 2002-05-10:</B> Reflected deliberations from the
Curacao (April, 2002) meeting.  Added issues 342-354.
</LI>
<LI>
<B>Revision 21: 2002-03-11:</B> Added new issues 314-341, updated issues
<A HREF="
     cwg_closed.html#132">132</A>,
<A HREF="
     cwg_defects.html#214">214</A>,
<A HREF="
     cwg_defects.html#244">244</A>,
<A HREF="
     cwg_defects.html#245">245</A>,
<A HREF="
     cwg_defects.html#254">254</A>,
<A HREF="
     cwg_active.html#255">255</A>,
<A HREF="
     cwg_defects.html#283">283</A>.
</LI>

<LI>
<B>Revision 20: 2001-11-09:</B> Reflected deliberations from the
Redmond (October, 2001) meeting.  Added issue <A HREF="
     cwg_closed.html#313">313</A>.
</LI>

<LI>
<B>Revision 19: 2001-09-12:</B> Added new issues 289-308, updated
issues <A HREF="
     cwg_defects.html#222">222</A>, <A HREF="
     cwg_defects.html#261">261</A>,
<A HREF="
     cwg_defects.html#270">270</A>.
</LI>

<LI>
<B>Revision 18: 2001-05-19:</B> Reflected deliberations from the
Copenhagen (April, 2001) meeting.  Added new issues 282-288.
</LI>

<LI>
<B>Revision 17: 2001-04-29:</B> Added new issues 276-81.
</LI>

<LI>
<B>Revision 16: 2001-03-27:</B> Updated <A HREF="
     cwg_active.html#138">issue 138</A> to discuss the interaction of <I>using-declaration</I>s
and "forward declarations."  Noted a problem with the proposed
resolution of <A HREF="
     cwg_defects.html#139">issue 139</A>.  Added some
new discussion to  <A HREF="
     cwg_defects.html#115">issue 115</A>.  Added
proposed resolution for <A HREF="
     cwg_defects.html#160">issue 160</A>.  Updated
address of C++ FAQ.  Added new issues 265-275.
</LI>

<LI>
<B>Revision 15: 2000-11-18:</B> Reflected deliberations from the
Toronto (October, 2000) meeting; moved the discussion of empty and
fully-initialized const objects from <A HREF="
     cwg_defects.html#78">issue 78</A> into <A HREF="
     cwg_active.html#253">new issue 253</A>;
added new issues 254-264.
</LI>

<LI>
<B>Revision 14: 2000-10-21:</B> Added issues 246-252; added an extra
question to <A HREF="
     cwg_defects.html#221">issue 221</A> and changed its
status back to "review."
</LI>

<LI>
<B>Revision 13: 2000-09-16:</B> Added issues 229-245; changed status
of <A HREF="
     cwg_defects.html#106">issue 106</A> to "review" because of problem
detected in proposal; added wording for issues <A HREF="
     cwg_defects.html#87">87</A> and <A HREF="
     cwg_defects.html#216">216</A> and moved to "review"
status; updated discussion of issues
<A HREF="
     cwg_defects.html#5">5</A>,
<A HREF="
     cwg_defects.html#78">78</A>,
<A HREF="
     cwg_defects.html#198">198</A>,
<A HREF="
     cwg_closed.html#203">203</A>, and
<A HREF="
     cwg_defects.html#222">222</A>.
</LI>

<LI>
<B>Revision 12: 2000-05-21:</B> Reflected deliberations from the
Tokyo (April, 2000) meeting; added new issues 222-228.
</LI>

<LI>
<B>Revision 11, 2000-04-13:</B> Added proposed wording and moved
issues
<A HREF="
     cwg_defects.html#62">62</A>,
<A HREF="
     cwg_defects.html#73">73</A>,
<A HREF="
     cwg_defects.html#89">89</A>,
<A HREF="
     cwg_defects.html#94">94</A>,
<A HREF="
     cwg_defects.html#106">106</A>,
<A HREF="
     cwg_defects.html#121">121</A>,
<A HREF="
     cwg_defects.html#134">134</A>,
<A HREF="
     cwg_defects.html#142">142</A>, and
<A HREF="
     cwg_defects.html#145">145</A>
to "review" status.  Moved <A HREF="
     cwg_closed.html#13">issue 13</A>
from "extension" to "open" status because of recent additional
discussion.
Added new issues 217-221.
</LI>

<LI>
<B>Revision 10, 2000-03-21:</B> Split the issues list and indices into
multiple documents.  Added further discussion to issues
<A HREF="
     cwg_defects.html#84">84</A> and <A HREF="
     cwg_defects.html#87">87</A>.
Added proposed wording and moved issues
<A HREF="
     cwg_defects.html#1">1</A>,
<A HREF="
     cwg_defects.html#69">69</A>,
<A HREF="
     cwg_defects.html#85">85</A>,
<A HREF="
     cwg_defects.html#98">98</A>,
<A HREF="
     cwg_defects.html#105">105</A>,
<A HREF="
     cwg_defects.html#113">113</A>,
<A HREF="
     cwg_closed.html#132">132</A>, and
<A HREF="
     cwg_defects.html#178">178</A>
to "review" status.
Added new issues 207-216.
</LI>

<LI><B>Revision 9, 2000-02-23:</B> Incorporated decisions from the
October, 1999 meeting of the Committee;

added issues 174 through 206.</LI>

<LI><B>Revision 8, 1999-10-13:</B> Minor editorial changes to issues
<A HREF="
     cwg_defects.html#90">90</A> and
<A HREF="
     cwg_defects.html#24">24</A>; updated issue
<A HREF="
     cwg_defects.html#89">89</A> to include a related question;
added issues
<A HREF="
     cwg_closed.html#169">169</A>,
<A HREF="
     cwg_active.html#170">170</A>,
<A HREF="
     cwg_defects.html#171">171</A>,
<A HREF="
     cwg_defects.html#172">172</A>, and
<A HREF="
     cwg_defects.html#173">173</A>.</LI>

<LI><B>Revision 7, 1999-09-14:</B> Removed unneeded change to
14.7.3 [temp.expl.spec] paragraph 9 from
<A HREF="
     cwg_defects.html#24">issue 24</A>; changed
<A HREF="
     cwg_defects.html#85">issue 85</A> to refer to
3.4.4 [basic.lookup.elab];
added issues
<A HREF="
     cwg_defects.html#122">122</A>,
<A HREF="
     cwg_defects.html#123">123</A>,
<A HREF="
     cwg_defects.html#124">124</A>,
<A HREF="
     cwg_defects.html#125">125</A>,
<A HREF="
     cwg_defects.html#126">126</A>,
<A HREF="
     cwg_defects.html#127">127</A>,
<A HREF="
     cwg_defects.html#128">128</A>,
<A HREF="
     cwg_defects.html#129">129</A>,
<A HREF="
     cwg_closed.html#130">130</A>,
<A HREF="
     cwg_defects.html#131">131</A>,
<A HREF="
     cwg_closed.html#132">132</A>,
<A HREF="
     cwg_closed.html#133">133</A>,
<A HREF="
     cwg_defects.html#134">134</A>,
<A HREF="
     cwg_defects.html#135">135</A>,
<A HREF="
     cwg_defects.html#136">136</A>,
<A HREF="
     cwg_defects.html#137">137</A>,
<A HREF="
     cwg_active.html#138">138</A>,
<A HREF="
     cwg_defects.html#139">139</A>,
<A HREF="
     cwg_defects.html#140">140</A>,
<A HREF="
     cwg_defects.html#141">141</A>,
<A HREF="
     cwg_defects.html#142">142</A>,
<A HREF="
     cwg_defects.html#143">143</A>,
<A HREF="
     cwg_active.html#144">144</A>,
<A HREF="
     cwg_defects.html#145">145</A>,
<A HREF="
     cwg_active.html#146">146</A>,
<A HREF="
     cwg_defects.html#147">147</A>,
<A HREF="
     cwg_defects.html#148">148</A>,
<A HREF="
     cwg_defects.html#149">149</A>,
<A HREF="
     cwg_active.html#150">150</A>,
<A HREF="
     cwg_defects.html#151">151</A>,
<A HREF="
     cwg_defects.html#152">152</A>,
<A HREF="
     cwg_defects.html#153">153</A>,
<A HREF="
     cwg_closed.html#154">154</A>,
<A HREF="
     cwg_closed.html#155">155</A>,
<A HREF="
     cwg_active.html#156">156</A>,
<A HREF="
     cwg_active.html#157">157</A>,
<A HREF="
     cwg_defects.html#158">158</A>,
<A HREF="
     cwg_defects.html#159">159</A>,
<A HREF="
     cwg_defects.html#160">160</A>,
<A HREF="
     cwg_defects.html#161">161</A>,
<A HREF="
     cwg_defects.html#162">162</A>,
<A HREF="
     cwg_defects.html#163">163</A>,
<A HREF="
     cwg_defects.html#164">164</A>,
<A HREF="
     cwg_closed.html#165">165</A>,
<A HREF="
     cwg_defects.html#166">166</A>,
<A HREF="
     cwg_closed.html#167">167</A>, and
<A HREF="
     cwg_closed.html#168">168</A>.</LI>

<LI><B>Revision 6, 1999-05-31:</B> Moved
<A HREF="
     cwg_closed.html#72">issue 72</A> to "dup" status; added
proposed wording and moved <A HREF="
     cwg_defects.html#90">issue 90</A>
to "review" status; updated <A HREF="
     cwg_defects.html#98">issue 98</A>
with additional question; added issues
<A HREF="
     cwg_active.html#110">110</A>,
<A HREF="
     cwg_closed.html#111">111</A>,
<A HREF="
     cwg_defects.html#112">112</A>,
<A HREF="
     cwg_defects.html#113">113</A>,
<A HREF="
     cwg_closed.html#114">114</A>,
<A HREF="
     cwg_defects.html#115">115</A>,
<A HREF="
     cwg_defects.html#116">116</A>,
<A HREF="
     cwg_closed.html#117">117</A>,
<A HREF="
     cwg_defects.html#118">118</A>,
<A HREF="
     cwg_defects.html#119">119</A>,
<A HREF="
     cwg_defects.html#120">120</A>, and
<A HREF="
     cwg_defects.html#121">121</A>.</LI>

<LI><B>Revision 5, 1999-05-24:</B> Reordered issues by status; added revision
history; first public version.</LI>
</UL>

<A NAME="Issue Status"></A>
<H3>Issue status</H3>

<P>Issues progress through various statuses as the Core Language
Working Group and, ultimately, the full PL22.16 and WG21 committees
deliberate and act.  For ease of reference, issues are grouped in these
documents by their status.  Issues have one of the following statuses:</P>

<P><B>Open:</B> The issue is new or the working group has not yet
formed an opinion on the issue.  If a <I>Suggested Resolution</I> is
given, it reflects the opinion of the issue's submitter, not
necessarily that of the working group or the Committee as a whole.</P>

<P><B>Drafting:</B> Informal consensus has been reached in the
working group and is described in rough terms in a <I>Tentative
Resolution</I>, although precise wording for the change is not yet
available.</P>

<P><B>Review:</B> Exact wording of a <I>Proposed Resolution</I> is now
available for an issue on which the working group previously reached
informal consensus.</P>

<P><B>Ready:</B> The working group has reached consensus that a change
in the working draft is required, the <I>Proposed Resolution</I> is
correct, and the issue is ready to forward to the full Committee for
ratification.</P>

<P><B>Tentatively Ready:</B> Like "ready" except that the resolution
was produced and approved by a subset of the working group membership
between meetings.  Persons not participating in these between-meeting
activities are encouraged to review such resolutions carefully and to
alert the working group with any problems that may be found.</P>

<P><B>DR:</B> The full Committee has approved the item as a proposed
defect report.  The <I>Proposed Resolution</I> in an issue with this
status reflects the best judgment of the Committee at this time
regarding the action that will be taken to remedy the defect; however,
the current wording of the Standard remains in effect until such time
as a <I>Technical Corrigendum</I> or a revision of the Standard is
issued by ISO.</P>

<P><B>Accepted:</B> Like a DR except that the issue concerns the
wording of the current Working Paper rather than that of the current
International Standard.</P>

<P><B>TC1:</B> A DR issue included in Technical Corrigendum 1.
TC1 is a revision of the Standard issued in 2003.</P>

<P><B>CD1:</B> A DR issue not resolved in TC1 but included in
Committee Draft 1.  CD1 was advanced for balloting at the
September, 2008 WG21 meeting.</P>

<P><B>CD2:</B> A DR issue not resolved in CD1 but included in
the Final Committee Draft advanced for balloting at the
March, 2010 WG21 meeting.</P>

<P><B>FDIS:</B> A DR issue not resolved in the FCD but included
in the Final Draft International Standard advanced for balloting
at the March, 2011 WG21 meeting.</P>

<P><B>DRWP:</B> A DR issue whose resolution is reflected in
the current Working Paper.  The Working Paper is a draft for a
future version of the Standard.</P>

<P><B>WP:</B> An Accepted issue whose resolution is reflected in
the current Working Paper.</P>

<P><B>Dup:</B> The issue is identical to or a subset of another issue,
identified in a <I>Rationale</I> statement.</P>

<P><B>NAD:</B> The working group has reached consensus that the issue
is not a defect in the Standard. A <I>Rationale</I> statement
describes the working group's reasoning.</P>

<P><B>Extension:</B> The working group has reached consensus that the
issue is not a defect in the Standard but is a request for an
extension to the language.  The working group
expresses no opinion on the merits of an issue with this status;
however, the issue will be maintained on the list for possible future
consideration as an extension proposal.</P>

<P><B>Concepts:</B> The issue relates to the &#8220;Concepts&#8221;
proposal that was removed from the working paper at the Frankfurt (July,
2009) meeting and hence is no longer under consideration.
</P>

<P><B>Concurrency:</B> The issue deals with concurrency and is to be
handled by the Concurrency Working Group within WG21.</P>
<HR><A NAME="Ready Status"></A><H3>Issues with "Ready" Status</H3>
<HR><A NAME="1775"></A><H4>1775.
  
Undefined behavior of line splice in raw string literal
</H4><B>Section: </B>2.2&#160; [lex.phases]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Canada
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-24<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA26">N3690 comment
  CA&#160;26<BR></A>

<P>According to phase 2 of 2.2 [lex.phases] paragraph 1,</P>

<BLOCKQUOTE>

Each instance of a backslash character (<TT>\</TT>) immediately followed by
a new-line character is deleted, splicing physical source lines to form
logical source lines. Only the last backslash on any physical source line
shall be eligible for being part of such a splice. If, as a result, a
character sequence that matches the syntax of a universal-character-name is
produced, the behavior is undefined.

</BLOCKQUOTE>

<P>There does not appear to be a good reason for the behavior to be
undefined when the line splice occurs within a raw string literal, since
the splicing will be reverted (2.5 [lex.pptoken] paragraph 3).</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change 2.2 [lex.phases] paragraph 1 phase 2 as follows:</P>

<OL start="2"><LI>

<P>Each instance of a backslash character (<TT>\</TT>) immediately followed
by a new-line character is deleted, splicing physical source lines to form
logical source lines. Only the last backslash on any physical source line
shall be eligible for being part of such a splice. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">If, as a
result,</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">Except for splices reverted in a raw string literal, if
a splice results in</SPAN> a character sequence that matches the syntax of a
universal-character-name <SPAN style="text-decoration:line-through;background-color:#FFA0A0">is produced</SPAN>, the behavior is
undefined. A source file that is not empty and that does not end in a
new-line character, or that ends in a new-line character immediately
preceded by a backslash character before any such splicing takes place,
shall be processed as if an additional new-line character were appended to
the file.</P></LI>

</OL>

<BR><BR><HR><A NAME="1717"></A><H4>1717.
  
Missing specification of type of binary literal
</H4><B>Section: </B>2.14.2&#160; [lex.icon]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-07-23<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#ES7">N3690 comment
  ES&#160;7<BR></A>



<P>Table 6 of 2.14.2 [lex.icon] paragraph 2 covers only
decimal, octal, and hexadecimal literals.  Binary literals should
be treated like the latter two.  (It would also be more consistent
to refer to these as &#8220;literals&#8221; instead of
&#8220;constants.&#8221;)</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change the caption and header row of Table 6 in
2.14.2 [lex.icon] paragraph 2 as follows:</P>

<P><TABLE WIDTH="100%"><TR><TD ALIGN="CENTER"><B>Table 6 &#8212; Types of integer <SPAN style="text-decoration:line-through;background-color:#FFA0A0">constants</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">literals</SPAN></B></TD></TR></TABLE></P>

<P><TABLE WIDTH="100%" BORDER="1"><TR>
<TH>Suffix</TH>
<TH>Decimal <SPAN style="text-decoration:line-through;background-color:#FFA0A0">constants</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">literal</SPAN></TH>
<TH><SPAN style="font-weight:bold;background-color:#A0FFA0">Binary,</SPAN> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">Octal</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">octal,</SPAN> or hexadecimal <SPAN style="text-decoration:line-through;background-color:#FFA0A0">constant</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">literal</SPAN></TH>
</TR></TABLE></P>

<BR><BR><HR><A NAME="1741"></A><H4>1741.
  
odr-use of class object in lvalue-to-rvalue conversion
</H4><B>Section: </B>3.2&#160; [basic.def.odr]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-08-21<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA28">N3690 comment
  CA&#160;28<BR></A>



<P>According to 4.1 [conv.lval] paragraph 2,</P>

<BLOCKQUOTE>

if the glvalue has a class type, the [lvalue-to-rvalue] conversion
copy-initializes a temporary of type <TT>T</TT> from the glvalue and the
result of the conversion is a prvalue for the temporary.

</BLOCKQUOTE>

<P>The implications of such a conversion for odr-use do not appear to have
been factored into 3.2 [basic.def.odr] paragraph 3, which exempts
constant objects that are immediately lvalue-to-rvalue converted.  For
example, given</P>

<PRE>
  struct S { int n; };
  struct T {
    static constexpr S s = {};
  };
  void f(...);
  void g() { f(T::s); }
</PRE>

<P>Does this odr-use <TT>T::s</TT>, requiring it to have a definition,
because of binding it to the reference parameter of <TT>S</TT>'s
copy constructor?  How about</P>

<PRE>
  struct S { int n; };
  void f(...);
  void g() {
    constexpr S s = {};
    [] { f(s); };
  }
</PRE>

<P>Does <TT>s</TT> need to be captured?  There is implementation variance
on both these examples.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change 3.2 [basic.def.odr] paragraph 3 as follows:</P>

<BLOCKQUOTE>

A variable <TT>x</TT> whose name appears as a potentially-evaluated
expression <TT>ex</TT> is <I>odr-used</I> unless <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>x</TT> satisfies
the requirements for appearing in a constant expression
(5.19 [expr.const])</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">applying the lvalue-to-rvalue
conversion (4.1 [conv.lval]) to <TT>x</TT> yields a constant
expression (5.19 [expr.const]) that does not invoke any non-trivial
functions</SPAN> and, if <TT>x</TT> is an object, <TT>ex</TT> is an element
of the set of potential results of an expression <TT>e</TT>, where either
the lvalue-to-rvalue conversion (4.1 [conv.lval]) is applied
to <TT>e</TT>, or <TT>e</TT> is a discarded-value expression (Clause
5 [expr]). <TT>this</TT> is odr-used...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1690"></A><H4>1690.
  
Associated namespace for local type
</H4><B>Section: </B>3.4.2&#160; [basic.lookup.argdep]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Ville Voutilainen
 &#160;&#160;&#160;

 <B>Date: </B>2013-05-27<BR>




<P>We can return a lambda or an object of a local class type from a lambda
in c++11, and we can return them from normal functions in c++14.  If those
lambdas and normal functions are in a namespace, the returned
lambdas/local-classes apparently aren't in that namespace, or even if they
are, ADL won't find them.  Is this intended?</P>

<P>(See also <A HREF="
     cwg_active.html#1664">issue 1664</A>.)</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>This issue is resolved by the resolution of
<A HREF="
     cwg_active.html#1691">issue 1691</A>.</P>

<BR><BR><HR><A NAME="1691"></A><H4>1691.
  
Argument-dependent lookup and opaque enumerations
</H4><B>Section: </B>3.4.2&#160; [basic.lookup.argdep]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>David Krauss
 &#160;&#160;&#160;

 <B>Date: </B>2013-05-27<BR>


<P>According to 3.4.2 [basic.lookup.argdep] paragraph 2,</P>

<BLOCKQUOTE>

If <TT>T</TT> is an enumeration type, its associated namespace is the
namespace in which it is defined. If it is class member, its associated
class is the member's class; else it has no associated class.

</BLOCKQUOTE>

<P>This does not take into account opaque enumerations, which can be
defined in an enclosing namespace of the one of which is a member.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change 3.4.2 [basic.lookup.argdep] paragraph 2 as follows:</P>

<BLOCKQUOTE>

<P>...The sets of namespaces and classes are determined in the following
way:</P>

<UL><LI><P>...</P></LI>

<LI><P>If <TT>T</TT> is a class type (including unions), its associated
classes are: the class itself; the class of which it is a member, if any;
and its direct and indirect base classes. Its associated namespaces are the
<SPAN style="font-weight:bold;background-color:#A0FFA0">innermost enclosing</SPAN> namespaces of <SPAN style="text-decoration:line-through;background-color:#FFA0A0">which</SPAN> its
associated classes <SPAN style="text-decoration:line-through;background-color:#FFA0A0">are members</SPAN>. Furthermore..</P></LI>

<LI><P>If <TT>T</TT> is an enumeration type, its associated namespace is
the <SPAN style="font-weight:bold;background-color:#A0FFA0">innermost enclosing</SPAN> namespace <SPAN style="text-decoration:line-through;background-color:#FFA0A0">in which it is
defined</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">of its declaration</SPAN>. If it is <SPAN style="font-weight:bold;background-color:#A0FFA0">a</SPAN> class
member, its associated class is the member's class; else it has no
associated class.</P></LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<P>This resolution also resolves issues <A HREF="
     cwg_active.html#1690">1690</A>
and <A HREF="
     cwg_active.html#1692">1692</A>.</P>

<BR><BR><HR><A NAME="1692"></A><H4>1692.
  
Associated namespaces of doubly-nested classes
</H4><B>Section: </B>3.4.2&#160; [basic.lookup.argdep]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>David Krauss
 &#160;&#160;&#160;

 <B>Date: </B>2013-05-29<BR>


<P>According to 3.4.2 [basic.lookup.argdep] paragraph 2,</P>

<BLOCKQUOTE>

If <TT>T</TT> is a class type (including unions), its associated classes
are: the class itself; the class of which it is a member, if any; and its
direct and indirect base classes. Its associated namespaces are the
namespaces of which its associated classes are members.

</BLOCKQUOTE>

<P>Consider an example like</P>

<PRE>
  struct A {
    struct B {
      struct C { };
    };
  };
</PRE>

<P><TT>A</TT> has one associated class, itself, and has the global
namespace as its associated namespace.  <TT>A::B</TT> has two associated
classes, <TT>A</TT> and itself, and by virtue of its association with
<TT>A</TT>, has the global namespace as its associated namespace.
<TT>A::B::C</TT> has two associated classes, <TT>A::B</TT> and itself.
However, because neither <TT>A::B</TT> nor <TT>A::B::C</TT> is a
member of a namespace, <TT>A::B::C</TT> has no associated namespaces.</P>

<P>This seems like a defect.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>This issue is resolved by the resolution of
<A HREF="
     cwg_active.html#1691">issue 1691</A>.</P>

<BR><BR><HR><A NAME="1773"></A><H4>1773.
  
Out-of-lifetime lvalue-to-rvalue conversion
</H4><B>Section: </B>4.1&#160; [conv.lval]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Canada
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-24<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA14">N3690 comment
  CA&#160;14<BR></A>

<P>Consider an example like the following:</P>

<PRE>
  struct Base { 
    virtual int call() = 0; 
  }; 
  Base *foo() { 
    constexpr int x = 0; 
    struct Local : Base { 
      virtual int call() { return x; } 
    }; 
    static Local local; 
    return &amp;local; 
  } 

  int main() { 
    return foo()-&gt;call(); 
  } 
</PRE>

<P>While the likely intention is that the lvalue-to-rvalue conversion of
the block-scope constant is implemented by using the value of the constant
expression in place of reading from storage, it seems that the wording of
4.1 [conv.lval] paragraph 2 does not prevent this program from
being subject to undefined behaviour caused by lifetime violation.  In
particular, it seems that a name expression that appears in a
potentially-evaluated expression such that the object named is not odr-used
(by that instance of the name) may still be evaluated, in theory, as an
lvalue through which the object named or a subobject thereof is
accessed.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change 4.1 [conv.lval] paragraph 2 as follows:</P>

<BLOCKQUOTE>

<P>When an lvalue-to-rvalue conversion <SPAN style="text-decoration:line-through;background-color:#FFA0A0">occurs in an unevaluated
operand or a subexpression thereof (Clause
5 [expr])</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is applied to an expression
<TT>e</TT>, and either</SPAN></P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>e</TT> is not potentially evaluated, or</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">the evaluation of <TT>e</TT> results in the evaluation of a
member <TT>ex</TT> of the set of potential results of <TT>e</TT>, and
<TT>ex</TT> names a variable <TT>x</TT> that is not odr-used by
<TT>ex</TT> (3.2 [basic.def.odr]),</SPAN></P></LI>

</UL>

<P>the value contained in the referenced object is not accessed.
<SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  struct S { int n; };
  auto f() {
    S x { 1 };
    constexpr S y { 2 };
    return [&amp;](bool b) { return (b ? y : x).n; };
  }
  auto g = f();
  int m = g(false); //<SPAN style="font-family:Times;font-style:italic"> undefined behavior due to access of </SPAN>x.n<SPAN style="font-family:Times;font-style:italic"> outside its lifetime</SPAN>
  int n = g(true);  //<SPAN style="font-family:Times;font-style:italic"> OK, does not access </SPAN>y.n</SPAN>
</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end example</I>]</SPAN> In all other cases, the result
of the conversion...</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1607"></A><H4>1607.
  
Lambdas in template parameters
</H4><B>Section: </B>5.1.2&#160; [expr.prim.lambda]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2013-01-19<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA3">N3690 comment
  CA&#160;3<BR></A>



<P>Lambda expressions cannot appear in unevaluated operands nor in
evaluated portions of constant expressions.  However, the following
example appears to circumvent those restrictions:</P>

<PRE>
  template &lt;bool&gt; struct BoolSink { typedef void type; };

  template &lt;typename T, typename U&gt;
  struct AddRvalueReferenceImpl { typedef T type; };

  template &lt;typename T&gt;
  struct AddRvalueReferenceImpl&lt;T, typename BoolSink&lt;false &amp;&amp;
     [] {
       extern T &amp;&amp;tref;
     }&gt;::type&gt; {
    typedef T &amp;&amp;type;
  };

  template &lt;typename T&gt;
  struct AddRvalueReference : AddRvalueReferenceImpl&lt;T, void&gt; { };

  namespace ImplHelpers {
    template &lt;typename T&gt;
    typename AddRvalueReference&lt;T&gt;::type create(void) { }
  }

  template &lt;typename T, typename U, typename ...Args&gt;
  struct IsConstructibleImpl { enum { value = 0 }; };

  template &lt;typename T, typename ...Args&gt;
  struct IsConstructibleImpl&lt;T, typename BoolSink&lt;false &amp;&amp;
     [] {
       T t( ::ImplHelpers::create&lt;Args&gt;() ...);
     }&gt;::type, Args ...&gt; {
    enum { value = 1 };
  };

  template &lt;typename T, typename ...Args&gt;
  struct IsConstructible : IsConstructibleImpl&lt;T, void, Args ...&gt; { };

  struct DestroyMe {
    ~DestroyMe() = delete;
  };

  static_assert(+IsConstructible&lt;int&gt;::value, "error");
  static_assert(!IsConstructible&lt;void&gt;::value, "error");
  static_assert(+IsConstructible&lt;int [1]&gt;::value, "error");
  static_assert(!IsConstructible&lt;DestroyMe&gt;::value, "error");
  static_assert(!IsConstructible&lt;int *, char *&gt;::value, "error");

  static_assert(+IsConstructible&lt;int &amp;&amp;, int&gt;::value, "error");
  static_assert(!IsConstructible&lt;int &amp;&amp;, int &amp;&gt;::value, "error");
  static_assert(+IsConstructible&lt;int &amp;&amp;, int &amp;&amp;&gt;::value, "error");
</PRE>

<P>Is this intended?</P>

<P><B>Additional notes, April, 2013:</B></P>

<P>Further discussion has arisen
regarding <I>lambda-expression</I>s in function template
signatures.   Although the
restriction that <I>lambda-expression</I>s cannot appear as
unevaluated operands (5.1.2 [expr.prim.lambda] paragraph
2) was intended to avert the need to deal with them in
function template signatures, the fact that
5.19 [expr.const] treats unevaluated
subexpressions separately from unevaluated operands opens
another avenue for <I>lambda-expression</I>s in template
signatures, e.g.,</P>

<PRE>
  template&lt;typename T&gt;
  void f(int [(0 &amp;&amp; [] { for (auto x : T()) {} }, 1)]);
</PRE>

<P>Four possible approaches for dealing with this issue have been
suggested:</P>

<OL><LI><P>Allow <I>lambda-expression</I>s in function
template signatures.  This would be costly in some
implementations.</P></LI>

<LI><P>Give a function template internal linkage if its
signature includes a <I>lambda-expression</I>.  This would
allow SFINAE and redeclaration to work without requiring
that <I>lambda-expression</I>s be mangled.</P></LI>

<LI><P>Specify that a function signature containing a
<I>lambda-expression</I> is not a redeclaration of any other
function template, which would allow SFINAE to work but not
require declaration matching and mangling.</P></LI>

<LI><P>Do not allow <I>lambda-expression</I>s in function
template signatures.</P></LI>

</OL>

<P>If any of these approaches were adopted, the rationale for
disallowing <I>lambda-expression</I>s in unevaluated operands would
be removed, so it might make sense to remove the restriction at the
same time.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change 5.1.2 [expr.prim.lambda] paragraph 2 as follows:</P>

<BLOCKQUOTE>

...A <I>lambda-expression</I> shall not appear in an unevaluated operand
(Clause 5 [expr])<SPAN style="font-weight:bold;background-color:#A0FFA0">, in a <I>template-argument</I>, in
an <I>alias-declaration</I>, in a typedef declaration, or in the
declaration of a function or function template outside its function body
and default arguments [<I>Note:</I> The intention is to prevent lambdas
from appearing in a signature &#8212;<I>end note</I>]</SPAN>. [<I>Note:</I>
A closure object behaves like a function object
(20.10 [function.objects]). &#8212;<I>end note</I>]

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1612"></A><H4>1612.
  
Implicit lambda capture and anonymous unions
</H4><B>Section: </B>5.1.2&#160; [expr.prim.lambda]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2013-01-31<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA17">N3690 comment
  CA&#160;17<BR></A>



<P>It is not clear from the description of capturing in
5.1.2 [expr.prim.lambda] whether an implicit capture resulting
from the odr-use of a member of an anonymous union captures that
member or the anonymous union, and there is implementation
divergence.  For example,</P>

<PRE>
  int main() {
    static int result;
    struct A { int x; };
    struct B { int y; };
    union {
      A a; B b;
    };
    a.x = 1;
    [=]() mutable { a.x = 2; result = b.y; }();
    if (result == 1) return 0;
    throw 0;
  }
</PRE>

<P><B>Notes from the April, 2013 meeting:</B></P>

<P>CWG decided that an attempt to capture a member of an anonymous union
should be ill-formed.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<OL><LI><P>Change 5.1.2 [expr.prim.lambda] paragraph 15 as follows:</P></LI>

<BLOCKQUOTE>

...An array of runtime bound (8.3.4 [dcl.array]) <SPAN style="font-weight:bold;background-color:#A0FFA0">or a member
of an anonymous union</SPAN> shall not be captured by copy.

</BLOCKQUOTE>

<LI><P>Change 5.1.2 [expr.prim.lambda] paragraph 16 as follows:</P></LI>

<BLOCKQUOTE>

...It is unspecified whether additional unnamed non-static data members are
declared in the closure type for entities captured by
reference. <SPAN style="font-weight:bold;background-color:#A0FFA0">A member of an anonymous union shall not be captured by
reference.</SPAN> [<I>Note:</I>...

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1613"></A><H4>1613.
  
Constant expressions and lambda capture
</H4><B>Section: </B>5.1.2&#160; [expr.prim.lambda]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2013-01-31<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA16">N3690 comment
  CA&#160;16<BR></A>



<P>Since instances of a variable in constant expressions may be odr-uses, the ordering of:</P>

<UL><LI><P>constant expression evaluation,</P></LI>

<LI><P>the determination of implicit captures, and</P></LI>

<LI><P>the transformation to use closure members for odr-uses of captured
variables</P></LI>

</UL>

<P>may affect the semantics of a program such as the one below.</P>

<P>The transformation under 5.1.2 [expr.prim.lambda] paragraph 17
introduces uses of the <TT>this</TT> pointer of the <TT>operator()</TT>
in its <I>function-body</I>.  This instances of <TT>this</TT> are
invalid under <A HREF="
     cwg_defects.html#1369">issue 1369</A> if the transformation
is applied before the evaluation of the constant expressions.  Without
the resolution of <A HREF="
     cwg_defects.html#1369">issue 1369</A>, another
situation occurs where instances of <TT>this</TT> in the
<I>compound-statement</I> are transformed into class member access
expressions (see the initializations of <TT>addrEqA</TT> and
<TT>addrEqB</TT> below).</P>

<P>Also, for the initialization of <TT>nonZero</TT> below, the expression
fails to be a constant expression if the transformation is applied before
constant expression evaluation.</P>

<P>Finally, the answer to the static assertion changes depending on whether
the constant expression evaluation is performed before the transformation
as opposed to after and whether the proposed resolution
<A HREF="
     cwg_defects.html#1472">issue 1472</A> is enabled.</P>

<P>There appears to be implementation divergence regarding</P>

<UL><LI><P>whether the lexical instances of <TT>this</TT> in the
initialization of <TT>addrEqB</TT> is valid and</P></LI>

<LI><P>whether the static assertion should pass.</P></LI>

</UL>

<P>Using explicit value captures is not a panacea, since the
paragraph 17 transformations only apply to odr-uses.  As a result
of the resolution of <A HREF="
     cwg_defects.html#1472">issue 1472</A>, if the
reference <TT>r</TT> below happened to have been initialized with a
constant expression, the value of its (modifiable) target is not
captured; if the same target were specified in the initialization
of the reference with a non-constant expression, its value would be
captured.</P>

<PRE>
  struct A {
    void foo();
  };

  struct LitType { int val; };
  constexpr int ceFunc(const LitType &amp;x) { return x.val; }

  void A::foo() {
    constexpr LitType y = { 0 };
    static int z;
    int x, &amp;r = z;
    [=] {
     constexpr bool addrEqA = &amp;x == &amp;x;         //<SPAN style="font-family:Times;font-style:italic"> ill-formed under <A HREF="
     cwg_defects.html#1369">issue 1369</A> after transformation</SPAN>
                                                //<SPAN style="font-family:Times;font-style:italic"> under paragraph 17</SPAN>
     constexpr bool addrEqB = &amp;*this == &amp;*this; //<SPAN style="font-family:Times;font-style:italic"> well-formed after transformation under N3290</SPAN>
                                                //<SPAN style="font-family:Times;font-style:italic"> paragraph 17</SPAN>
     constexpr bool nonZero = ceFunc(y);        //<SPAN style="font-family:Times;font-style:italic"> lvalue-to-rvalue conversion occurs only after</SPAN>
                                                //<SPAN style="font-family:Times;font-style:italic"> function invocation substitution; the closure member,</SPAN>
                                                //<SPAN style="font-family:Times;font-style:italic"> being not a variable, cannot be </SPAN>constexpr
     static_assert(&amp;r != &amp;z,
       "reference which could be captured by value found to alias target");
                                                //<SPAN style="font-family:Times;font-style:italic"> affected by <A HREF="
     cwg_defects.html#1472">issue 1472</A></SPAN>
    };
  }
</PRE>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Add the following bullet to 5.19 [expr.const] paragraph 2:</P>

<BLOCKQUOTE>

<P>A <I>conditional-expression</I> <TT>e</TT> is a core constant expression
unless the evaluation of <TT>e</TT>, following the rules of the abstract
machine (1.9 [intro.execution]), would evaluate one of the following
expressions:</P>

<UL><LI><P>...</P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">in a <I>lambda-expression</I>, a reference to <TT>this</TT> or
to a variable with automatic storage duration defined outside
that <I>lambda-expression</I>, where the reference would be an odr-use
(3.2 [basic.def.odr], 5.1.2 [expr.prim.lambda]);</SPAN></P></LI>

<LI><P>a conversion from type <I>cv</I> <TT>void *</TT> to a
pointer-to-object type;</P></LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1662"></A><H4>1662.
  
Capturing function parameter packs
</H4><B>Section: </B>5.1.2&#160; [expr.prim.lambda]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-15<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA20">N3690 comment
  CA&#160;20<BR></A>



<P>The example in 5.1.2 [expr.prim.lambda] paragraph 24 reads,</P>

<PRE>
  template&lt;class... Args&gt;
  void f(Args... args) {
    auto lm = [&amp;, args...] { return g(args...); };
    lm();
  }
</PRE>

<P>However, it's not clear how this example squares with the
requirements in paragraph 10,</P>

<BLOCKQUOTE>

The identifier in a <I>simple-capture</I> is looked up using the usual
rules for unqualified name lookup (3.4.1 [basic.lookup.unqual]); each such
lookup shall find a variable with automatic storage duration declared in
the reaching scope of the local lambda expression.

</BLOCKQUOTE>

<P>since a function parameter pack is not a variable.  Although the
requirement might be met in a given specialization of the function
template, is there a rule that relaxes it in the context of the function
template definition?</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<OL><LI><P>Change 5.1.2 [expr.prim.lambda] paragraph 10 as follows:</P></LI>

<BLOCKQUOTE>

The <I>identifier</I> in a <I>simple-capture</I> is looked up using the
usual rules for unqualified name lookup (3.4.1 [basic.lookup.unqual]); each
such lookup shall find <SPAN style="font-weight:bold;background-color:#A0FFA0">an entity.  An entity that is designated by a
<I>simple-capture</I> is said to be <I>explicitly captured</I>, and shall
be <TT>this</TT> or</SPAN> a variable with automatic storage duration
declared in the reaching scope of the local lambda expression. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">An
entity (i.e. a variable or <TT>this</TT>) is said to be <I>explicitly
captured</I> if it is found by this process.</SPAN>

</BLOCKQUOTE>

<LI><P>Change 14.5.3 [temp.variadic] paragraph 4 as follows:</P></LI>

<BLOCKQUOTE>

<P>...Pack expansions can occur in the following contexts:</P>

<UL><LI><P>...</P></LI></UL>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">For the purpose of determining whether a parameter pack satisfies a
rule regarding entities other than parameter packs, the parameter pack is
considered to be the entity that would result from an instantiation of the
pattern in which it appears.</SPAN></P>

<P>[<I>Example:</I></P>...

</BLOCKQUOTE>

<LI><P>Change 14.5.3 [temp.variadic] paragraph 6 as follows:</P></LI>

<BLOCKQUOTE>

<P>...Each <TT>E</TT><SUB><I>i</I></SUB> is generated by instantiating the
pattern and replacing each pack expansion parameter with its <I>i</I>th
element. <SPAN style="font-weight:bold;background-color:#A0FFA0">Such an element, in the context of the instantiation, is
interpreted as follows:</SPAN></P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if the pack is a template parameter pack, the element is a
template parameter (14.1 [temp.param]) of the corresponding kind
(type or non-type) designating the type or value from the template
argument; otherwise,</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if the pack is a function parameter pack, the element is
an <I>id-expression</I> designating the function parameter that resulted
from the instantiation of the pattern where the pack is
declared.</SPAN></P></LI>

</UL>

<P>All of the <TT>E</TT><SUB><I>i</I></SUB> become elements in the
enclosing list. [<I>Note:</I>...</P>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1664"></A><H4>1664.
  
Argument-dependent lookup of lambdas used in default arguments
</H4><B>Section: </B>5.1.2&#160; [expr.prim.lambda]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-15<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA18">N3690 comment
  CA&#160;18<BR></A>



<P>According to 5.1.2 [expr.prim.lambda] paragraph 3,</P>

<BLOCKQUOTE>

The closure type is declared in the smallest block scope, class scope, or
namespace scope that contains the
corresponding <I>lambda-expression</I>. [<I>Note:</I> This determines the
set of namespaces and classes associated with the closure type
(3.4.2 [basic.lookup.argdep]). The parameter types of
a <I>lambda-declarator</I> do not affect these associated namespaces and
classes. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>However, 14.7.1 [temp.inst] paragraph 13 says,</P>

<BLOCKQUOTE>

If a function template <TT>f</TT> is called in a way that requires a
default argument to be used, the dependent names are looked up, the
semantics constraints are checked, and the instantiation of any template
used in the default argument is done as if the default argument had been an
initializer used in a function template specialization with the same scope,
the same template parameters and the same access as that of the function
template <TT>f</TT> used at that point.

</BLOCKQUOTE>

<P>A possibility, then, is that the closure type for a lambda expression in
a default argument for a template function (or, presumably, a member
function of a class template) is to be considered as having been declared
in some block scope in the body of the fictional function template
specialization.</P>

<P>Consider the following example:</P>

<PRE>
  namespace J {
    inline namespace K {
      template &lt;typename T&gt; int zap(const T &amp;t) { foo(t); return 0; }
      template &lt;typename T&gt; void zip(int = zap([] { })) { }
    }
    template &lt;typename T&gt; void foo(const T &amp;) { }
  }
  void bar() { J::K::zip&lt;long&gt;(); }
</PRE>

<P>If <TT>zip</TT> were not a template, argument-dependent lookup
successfully resolves the lookup for <TT>foo</TT> in all implementations
tested; however, there is implementation variance in the handling of the
example as written.</P>

<P>(See also <A HREF="
     cwg_active.html#1690">issue 1690</A>.)</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change 14.7.1 [temp.inst] paragraph 13 as follows:</P>

<BLOCKQUOTE>

If a function template <TT>f</TT> is called in a way that requires a
default argument to be used, the dependent names are looked up, the
semantics constraints are checked, and the instantiation of any template
used in the default argument is done as if the default argument had been an
initializer used in a function template specialization with the same scope,
the same template parameters and the same access as that of the function
template <TT>f</TT> used at that point<SPAN style="font-weight:bold;background-color:#A0FFA0">, except that the scope in which
a closure type is declared (5.12 [expr.xor]) &#8212; and
therefore its associated namespaces &#8212; remain as determined from the
context of the definition for the default argument</SPAN>. This analysis is
called <I>default argument instantiation</I>. The instantiated default
argument is then used as the argument of <TT>f</TT>.

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1681"></A><H4>1681.
  
<I>init-capture</I>s and nested lambdas
</H4><B>Section: </B>5.1.2&#160; [expr.prim.lambda]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-05-14<BR>




<P>According to 5.1.2 [expr.prim.lambda] paragraph 10,</P>

<BLOCKQUOTE>

The <I>identifier</I> in a <I>simple-capture</I> is looked up using the
usual rules for unqualified name lookup (3.4.1 [basic.lookup.unqual]); each
such lookup shall find a variable with automatic storage duration declared
in the reaching scope of the local lambda expression.

</BLOCKQUOTE>

<P>This does not permit a nested lambda to capture the non-static
data member of the closure type introduced by an <I>init-capture</I>.
A similar restriction applies to implicit capture in paragraph 12.</P>

<P>Presumably such captures should be allowed, capturing the non-static
data member directly rather than the <TT>this</TT> pointer from the
enclosing lambda's <TT>operator()</TT>.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>This issue is resolved by the resolution of
<A HREF="
     cwg_active.html#1760">issue 1760</A>.</P>

<BR><BR><HR><A NAME="1760"></A><H4>1760.
  
Access of member corresponding to <I>init-capture</I>
</H4><B>Section: </B>5.1.2&#160; [expr.prim.lambda]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>United Kingdom
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-23<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#GB3">N3690 comment
  GB&#160;3<BR></A>

<P>The access of the non-static data member corresponding to an
<I>init-capture</I> is not specified.  The question would be moot if
the member were unnamed like the other non-static data members of the
closure class.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<OL><LI>Change 5.1.2 [expr.prim.lambda] paragraph 11 as follows:</LI>

<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">For every <I>init-capture</I> a non-static data member named by the
<I>identifier</I> of the <I>init-capture</I> is declared in the closure
type. This member is not a bit-field and not <TT>mutable</TT>. The type of
that member corresponds to the type of a hypothetical</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">An
<I>init-capture</I> behaves as if it declares and explicitly captures
a</SPAN> variable <SPAN style="text-decoration:line-through;background-color:#FFA0A0">declaration</SPAN> of the form
&#8220;<TT>auto</TT> <I>init-capture</I> ;&#8221; <SPAN style="font-weight:bold;background-color:#A0FFA0">whose declarative
region is the <I>lambda-expression</I>'s <I>compound-statement</I></SPAN>,
except that <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the variable name (i.e., the <I>identifier</I> of
the <I>init-capture</I>) is replaced by a unique
identifier.</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">:</SPAN></P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if the capture is by copy (see below), the non-static data
member declared for the capture and the variable are treated as two
different ways of referring to the same object, which has the lifetime of
the non-static data member, and no additional copy and destruction is
performed, and</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if the capture is by reference, the variable's lifetime ends
when the closure object's lifetime ends.</SPAN></P></LI>

</UL>

<P>[<I>Note:</I> This enables an <I>init-capture</I> like &#8220;<TT>x =
std::move(x)</TT>&#8221;; the second &#8220;<TT>x</TT>&#8221; must bind to
a declaration in the surrounding context.  &#8212;<I>end note</I>] <SPAN style="text-decoration:line-through;background-color:#FFA0A0">No
entity is captured by an <I>init-capture</I>. Within
the <I>lambda-expression</I>s <I>lambda-declarator</I>
and <I>compound-statement</I>, the <I>identifier</I> in
the <I>init-capture</I> hides any declaration of the same name in scopes
enclosing the <I>lambda-expression</I>.</SPAN> [<I>Example:</I>...</P>

</BLOCKQUOTE>

<LI><P>Change 5.1.2 [expr.prim.lambda] paragraph 15 as follows:</P></LI>

<BLOCKQUOTE>

An entity is <I>captured by copy</I> if it is implicitly captured and
the <I>capture-default</I> is <TT>=</TT> or if it is explicitly captured
with a capture that <SPAN style="text-decoration:line-through;background-color:#FFA0A0">does not include an <TT>&amp;</TT></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is
not of the form <TT>&amp;</TT> <I>identifier</I>
or <TT>&amp;</TT> <I>identifier initializer</I></SPAN>. For each entity...

</BLOCKQUOTE>

<LI><P>Change 5.1.2 [expr.prim.lambda] paragraph 18 as follows:</P></LI>

<BLOCKQUOTE>

Every <I>id-expression</I> <SPAN style="font-weight:bold;background-color:#A0FFA0">within the <I>compound-statement</I> of
a <I>lambda-expression</I></SPAN> that is an odr-use
(3.2 [basic.def.odr]) of an entity captured by copy is transformed
into an access to the corresponding unnamed data member of the closure
type. [<I>Note:</I>...

</BLOCKQUOTE>

</OL>

<P>This resolution also resolves <A HREF="
     cwg_active.html#1681">issue 1681</A>.</P>

<BR><BR><HR><A NAME="1772"></A><H4>1772.
  
<TT>__func__</TT> in a lambda body
</H4><B>Section: </B>5.1.2&#160; [expr.prim.lambda]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Switzerland/Canada
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-24<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CH5">N3690 comment
  CH&#160;5<BR></A>
<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA22">N3690 comment
  CA&#160;22<BR></A>

<P>It is not clear whether <TT>__func__</TT> in the body of a lambda
refers to the <TT>operator()</TT> of the closure class or
to the containing function (if any).  Since lambdas can appear in
non-function scope, it would be preferable for them to refer to the
closure class's <TT>operator()</TT>.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change 5.1.2 [expr.prim.lambda] paragraph 7 as follows:</P>

<BLOCKQUOTE>

The <I>lambda-expression</I>'s <I>compound-statement</I> yields
the <I>function-body</I>... &#8212;<I>end example</I>] <SPAN style="font-weight:bold;background-color:#A0FFA0">Further, a
variable <TT>__func__</TT> is implicitly defined at the beginning of
the <I>compound-statement</I> of the <I>lambda-expression</I>, with
semantics as described in 8.4.1 [dcl.fct.def.general].</SPAN>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1376"></A><H4>1376.
  
<TT>static_cast</TT> of temporary to rvalue reference
</H4><B>Section: </B>5.2.9&#160; [expr.static.cast]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2011-08-17<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA1">N3690 comment
  CA&#160;1<BR></A>

<P>In a declaration like</P>

<PRE>
    T&amp;&amp; r = static_cast&lt;T&amp;&amp;&gt;(T());
</PRE>

<P>it is not clear what the lifetime of the <TT>T</TT> temporary
should be.  According to 5.2.9 [expr.static.cast] paragraph 4,
the <TT>static_cast</TT> is equivalent to a declaration of an invented
temporary variable <TT>t</TT>.  The lifetime of the temporary is
extended to that of <TT>t</TT>, but it is not clear what that lifetime
should be, nor if the subsequent binding of <TT>t</TT> to <TT>r</TT>
would affect the lifetime of the original temporary.  (See also
<A HREF="
     cwg_closed.html#1568">issue 1568</A>.)</P>

<P><B>Notes from the February, 2012 meeting:</B></P>

<P>The reference is bound to the xvalue result of the <TT>static_cast</TT>,
so the lifetime of the temporary is not extended and this example results
in a dangling reference.</P>

<P><B>Proposed resolution (February, 2012) [SUPERSEDED]:</B></P>

<P>Change 5.2.9 [expr.static.cast] paragraph 4 as follows:</P>

<BLOCKQUOTE>

Otherwise, an expression <TT>e</TT> can be explicitly converted to a
type <TT>T</TT> using a <TT>static_cast</TT> of the form
<TT>static_cast&lt;T&gt;(e)</TT> if the declaration
<TT>T&#160;t(e);</TT> is well-formed, for some invented
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">temporary</SPAN> variable <TT>t</TT> (8.5 [dcl.init]).
The effect...

</BLOCKQUOTE>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change 5.2.9 [expr.static.cast] paragraph 3 as follows:</P>

<BLOCKQUOTE>

A glvalue<SPAN style="font-weight:bold;background-color:#A0FFA0">, class prvalue, or array prvalue</SPAN> of type
&#8220;<I>cv1</I> <TT>T1</TT>&#8221; can be cast to type &#8220;rvalue
reference to <I>cv2</I> <TT>T2</TT>&#8221; if
&#8220;<I>cv2</I> <TT>T2</TT>&#8221; is reference-compatible with
&#8220;<I>cv1</I> <TT>T1</TT>&#8221; (8.5.3 [dcl.init.ref]). If the
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">glvalue</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">value</SPAN> is not a bit-field, the result refers
to the object or the specified base class subobject thereof; otherwise, the
lvalue-to-rvalue conversion (4.1 [conv.lval]) is applied to the
bit-field and the resulting prvalue is used as the <I>expression</I> of
the <TT>static_cast</TT> for the remainder of this section. If <TT>T2</TT>
is an inaccessible (Clause 11 [class.access]) or ambiguous
(10.2 [class.member.lookup]) base class of <TT>T1</TT>, a program that
necessitates such a cast is ill-formed.

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1767"></A><H4>1767.
  
Scoped enumeration in a <TT>switch</TT> statement
</H4><B>Section: </B>6.4.2&#160; [stmt.switch]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Canada
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-23<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA8">N3690 comment
  CA&#160;8<BR></A>

<P>The description of the <TT>switch</TT> statement and case labels in
6.4.2 [stmt.switch] paragraph 2 apply integral promotions to the
condition value and refer to the &#8220;promoted type&#8221; of the
condition.  However, the integral promotions (4.5 [conv.prom])
do not describe the result when they are applied to a scoped enumeration
value.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change 6.4.2 [stmt.switch] paragraph 2 as follows:</P>

<BLOCKQUOTE>

<P>The condition shall be of integral type, enumeration type, or class
type. If of class type, the condition is contextually implicitly converted
(Clause 4 [conv]) to an integral or enumeration
type. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">Integral promotions are performed.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">If the (possibly
converted) type is subject to integral promotions
(4.5 [conv.prom]), the condition is converted to the promoted
type.</SPAN> Any statement within the <TT>switch</TT> statement can be
labeled with one or more case labels as follows:</P>

<UL><TT>case</TT> <I>constant-expression</I> <TT>:</TT></UL>

<P>where the <I>constant-expression</I> shall be a converted constant
expression (5.19 [expr.const]) of
the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">promoted</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">adjusted</SPAN> type of the switch
condition. No two of the case constants in the same switch shall have the
same value after conversion <SPAN style="text-decoration:line-through;background-color:#FFA0A0">to the promoted type of the switch
condition</SPAN>.</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1765"></A><H4>1765.
  
Overflow of enumeration used as enumerator value
</H4><B>Section: </B>7.2&#160; [dcl.enum]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Canada
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-23<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA7">N3690 comment
  CA&#160;7<BR></A>

<P>Regarding the value of an enumerator whose enumeration's underlying
type is not fixed, 7.2 [dcl.enum] paragraph 5 says,</P>

<BLOCKQUOTE>

the type of the initializing value is the same as the type of the
initializing value of the preceding enumerator unless the incremented value
is not representable in that type, in which case the type is an unspecified
integral type sufficient to contain the incremented value.

</BLOCKQUOTE>

<P>It is not clear how this is to be applied when the preceding
enumerator value is given by an enumerator whose value is the largest
of its enumeration's values, and there is implementation variance on
this point.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change 7.2 [dcl.enum] paragraph 5 as follows:</P>

<BLOCKQUOTE>

<P>...If the underlying type is fixed, the type of
each <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>enumerator</I></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">enumerator</SPAN> prior to the
closing brace is the underlying type and the <I>constant-expression</I> in
the <I>enumerator-definition</I> shall be a converted constant expression
of the underlying type (5.19 [expr.const])<SPAN style="text-decoration:line-through;background-color:#FFA0A0">; if the
initializing value of an enumerator cannot be represented by the underlying
type, the program is ill-formed</SPAN>. If the underlying type is not fixed,
the type of each enumerator <SPAN style="font-weight:bold;background-color:#A0FFA0">prior to the closing brace</SPAN>
is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the type of its initializing value</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">determined as
follows</SPAN>:</P>

<UL><LI><P>If an initializer is specified for an enumerator, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the
initializing value</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">the <I>constant-expression</I> shall be an
integral constant expression (5.19 [expr.const]).  If the
expression has unscoped enumeration type, the enumerator has the underlying
type of that enumeration type, otherwise it</SPAN> has the same type as the
expression <SPAN style="text-decoration:line-through;background-color:#FFA0A0">and the <I>constant-expression</I> shall be an integral
constant expression (5.19 [expr.const])</SPAN>.</P></LI>

<LI><P>If no initializer is specified for the first enumerator, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the
initializing value has</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">its type is</SPAN> an unspecified integral
type.</P></LI>

<LI><P>Otherwise the type of the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">initializing
value</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">enumerator</SPAN> is the same as <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the
type</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">that</SPAN> of <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the initializing value of</SPAN> the
preceding enumerator unless the incremented value is not representable in
that type, in which case the type is an unspecified integral type
sufficient to contain the incremented value. If no such type exists, the
program is ill-formed.</P></LI>

</UL>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1761"></A><H4>1761.
  
Runtime check on size of automatic array
</H4><B>Section: </B>8.3.4&#160; [dcl.array]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>USA
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-23<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#US10">N3690 comment
  US&#160;10<BR></A>

<P>The runtime check for violating the maximum size of a stack-based
array object is ill-advised.  Many implementations cannot easily
determine the available stack space, and checking against a fixed limit
is not helpful.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change 8.3.4 [dcl.array] paragraph 1 as follows:</P>

<BLOCKQUOTE>

<P>...The <I>expression</I> is erroneous if:</P>

<UL><LI><P>its value before converting...</P></LI>

<LI><P>its value is such that the size of the allocated object would exceed
the implementation-defined limit <SPAN style="font-weight:bold;background-color:#A0FFA0">for the maximum size of an
object</SPAN> (Annex B [implimits]);</P></LI>

<LI><P>...</P></LI>

</UL>

<P>...If the <I>expression</I> is erroneous, an exception of a type that
would match a handler (15.3 [except.handle]) of
type <TT>std::bad_array_length</TT> (18.6.2.2 [bad.array.length]) is
thrown <SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Footnote:</I> Implementations are encouraged also to
throw such an exception if the size of the object would exceed the
remaining stack space. &#8212;<I>end footnote</I>]</SPAN>.</P>

</BLOCKQUOTE>

<P>This resolution also resolves <A HREF="
     cwg_active.html#1675">issue 1675</A>.</P>

<BR><BR><HR><A NAME="1768"></A><H4>1768.
  
Zero-element array of runtime bound
</H4><B>Section: </B>8.3.4&#160; [dcl.array]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>USA
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-24<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#US9">N3690 comment
  US&#160;9<BR></A>

<P>C-style variable-length arrays (which have been widely implemented
as extensions to C++) permit a zero-length array.  Similarly, arrays
created by <I>new-expression</I>s can have a length of zero.  Forbidding
zero-length arrays of runtime bound is a gratuitous incompatibility.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<OL><LI><P>Change 8.3.4 [dcl.array] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<P>...The <I>expression</I> is erroneous if:</P>

<UL><LI><P>its value before converting to <TT>std::size_t</TT> or, in the
case of an expression of class type, before application of the second
standard conversion (13.3.3.1.2 [over.ics.user]) is less than <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or
equal to</SPAN> zero;</P></LI>

<LI><P>...</P></LI>

</UL>

<P>If the <I>expression</I>, after converting to <TT>std::size_t</TT>, is a
core constant expression and the expression is erroneous <SPAN style="font-weight:bold;background-color:#A0FFA0">or its value
is zero</SPAN>, the program is ill-formed.  If the <I>expression</I>...
<TT>std::bad_array_length</TT> (18.6.2.2 [bad.array.length]) is thrown.
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">An object of array type</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>N</TT> is zero, an object of
array type has no elements.  Otherwise, it</SPAN> contains a contiguously
allocated non-empty set of <TT>N</TT> subobjects of type <TT>T</TT>. The
type...</P>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1778"></A><H4>1778.
  
<I>exception-specification</I> in explicitly-defaulted functions
</H4><B>Section: </B>8.4.2&#160; [dcl.fct.def.default]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>USA
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-25<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#US23">N3690 comment
  US&#160;23<BR></A>



<P>According to 8.4.2 [dcl.fct.def.default] paragraph 2,</P>

<BLOCKQUOTE>

An explicitly-defaulted function may be declared <TT>constexpr</TT> only if
it would have been implicitly declared as <TT>constexpr</TT>, and may have an
explicit <I>exception-specification</I> only if it is compatible
(15.4 [except.spec]) with the <I>exception-specification</I> on the
implicit declaration.

</BLOCKQUOTE>

<P>The requirement for <I>exception-specification</I>s has unfortunate
consequences for the standard library component <TT>atomic</TT>, as
described
in <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2165">LWG
issue 2165</A>: the component cannot be used with a <TT>T</TT>
unless <TT>T</TT> is nothrow default constructible, even if
the <TT>std::atomic&lt;T&gt;</TT> variable is never default
initialized.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change 8.4.2 [dcl.fct.def.default] paragraphs 2 and 3 as follows:</P>

<BLOCKQUOTE>

<P>An explicitly-defaulted function may be declared <TT>constexpr</TT> only
if it would have been implicitly declared as <TT>constexpr</TT><SPAN style="text-decoration:line-through;background-color:#FFA0A0">, and
may have an explicit <I>exception-specification</I> only if it is
compatible (15.4 [except.spec]) with
the <I>exception-specification</I> on the implicit declaration</SPAN>. If a
function is explicitly defaulted on its first declaration,</P>

<UL><LI><P>it is implicitly considered to be <TT>constexpr</TT> if the
implicit declaration would be, and,</P></LI>

<LI><P>it is implicitly considered to have the
same <I>exception-specification</I> as if it had been implicitly declared
(15.4 [except.spec]).</P></LI>

</UL>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">If a function that is explicitly defaulted has an
explicit <I>exception-specification</I> that is not compatible
(15.4 [except.spec]) with the <I>exception-specification</I> on the
implicit declaration, then</SPAN></P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if the function is explicitly defaulted on its first
declaration, it is defined as deleted;</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">otherwise, the program is ill-formed.</SPAN></P></LI>

</UL>

<P>[<I>Example:</I></P>

<PRE>
  struct S {
    constexpr S() = default;            //<SPAN style="font-family:Times;font-style:italic"> ill-formed: implicit </SPAN>S()<SPAN style="font-family:Times;font-style:italic"> is not constexpr</SPAN>
    S(int a = 0) = default;             //<SPAN style="font-family:Times;font-style:italic"> ill-formed: default argument</SPAN>
    void operator=(const S&amp;) = default; //<SPAN style="font-family:Times;font-style:italic"> ill-formed: non-matching return type</SPAN>
    ~S() throw(int) = default;          //<SPAN style="font-family:Times;font-style:italic"> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">ill-formed</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">deleted</SPAN>: exception specification does not match</SPAN>
  private:
    int i;
    S(S&amp;);                              //<SPAN style="font-family:Times;font-style:italic"> OK: private copy constructor</SPAN>
  };
  S::S(S&amp;) = default;                   //<SPAN style="font-family:Times;font-style:italic"> OK: defines copy constructor</SPAN>
</PRE>

<P>&#8212;<I>end example</I>]</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1604"></A><H4>1604.
  
Double temporaries in reference initialization
</H4><B>Section: </B>8.5.3&#160; [dcl.init.ref]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2013-01-10<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA30">N3690 comment
  CA&#160;30<BR></A>



<P>Bullet 2 sub-bullet 2 of 8.5.3 [dcl.init.ref] paragraph 5 says,</P>

<BLOCKQUOTE>

Otherwise, a temporary of type &#8220;cv1 T1&#8221; is created and
initialized from the initializer expression using the rules for a
non-reference copy-initialization (8.5 [dcl.init]).  The
reference is then bound to the temporary.

</BLOCKQUOTE>

<P>It is not clear what &#8220;using the rules for a non-reference
copy-initialization&#8221; means.  If it means that the temporary
is initialized as if it were a standalone variable, the last bullet
of 8.5 [dcl.init] paragraph 17 could apply:</P>

<BLOCKQUOTE>

Otherwise (i.e., for the remaining copy-initialization cases),
user-defined conversion sequences that can convert from the source
type to the destination type or (when a conversion function is used)
to a derived class thereof are enumerated as described in 13.3.1.4 [over.match.copy], and the best one is chosen through overload
resolution (13.3 [over.match]). If the conversion cannot be
done or is ambiguous, the initialization is ill-formed.  The function
selected is called with the initializer expression as its argument; if
the function is a constructor, the call initializes a temporary of the
cv-unqualified version of the destination type. The temporary is a
prvalue. The result of the call (which is the temporary for the
constructor case) is then used to direct-initialize, according to the
rules above, the object that is the destination of the
copy-initialization.

</BLOCKQUOTE>

<P>That is, for an example like</P>

<PRE>
  struct X {
    X(int) {}
      X(X const &amp;) = delete;
    };

  void f() {
    X const &amp;x = 0;
  }
</PRE>

<P>the specification requires creation of a temporary <TT>X(0)</TT>,
copying that tempoary to another temporary (subject to copy elision),
and binding the reference to that second temporary.  In the example
above, because the copy constructor is deleted, the example is
ill-formed, although current implementations fail to diagnose it as
an error.</P>

<P>Is this intended?</P>



<P><B>Proposed resolution (September, 2013):</B></P>

<OL><LI><P>Change the last bullet of 8.5.3 [dcl.init.ref] paragraph
5, breaking it into sub-bullets, and the subsequent example as
follows:</P></LI>

<UL><LI><P>Otherwise<SPAN style="font-weight:bold;background-color:#A0FFA0">:</SPAN></P></LI>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>T1</TT> is a class type, user-defined conversions
are considered using the rules for copy-initialization of an object of type
&#8220;<I>cv1</I> <TT>T1</TT>&#8221; by user-defined conversion
(8.5 [dcl.init], 13.3.1.4 [over.match.copy]); the program is
ill-formed if the corresponding non-reference copy-initialization would be
ill-formed. The result of the call to the conversion function, as described
for the non-reference copy-initialization, is then used to
direct-initialize the reference. The program is ill-formed if the
direct-initialization does not result in a direct binding or if it involves
a user-defined conversion.</SPAN></P></LI>

<LI>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>T1</TT> is a non-class type</SPAN>, a temporary of type
&#8220;<I>cv1</I> <TT>T1</TT>&#8221; is created
and <SPAN style="font-weight:bold;background-color:#A0FFA0">copy-</SPAN>initialized (8.5 [dcl.init]) from the
initializer expression <SPAN style="text-decoration:line-through;background-color:#FFA0A0">using the rules for a non-reference
copy-initialization (8.5 [dcl.init])</SPAN>. The reference is then
bound to the temporary.</P></LI>

</UL>

<P>If <TT>T1</TT> is reference-related
to <TT>T2</TT><SPAN style="text-decoration:line-through;background-color:#FFA0A0">,</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">:</SPAN></P>

<UL><LI><P><I>cv1</I> shall be the same cv-qualification as, or greater
cv-qualification than, <I>cv2</I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">.</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">; and</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">If <TT>T1</TT> is reference-related to <TT>T2</TT> and</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">if</SPAN> the reference is an rvalue reference, the initializer
expression shall not be an lvalue.</P></LI>

</UL>

</UL>

<P>[<I>Example:</I></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  struct Banana { };
  struct Enigma { operator const Banana(); };
  void enigmatic() {
    typedef const Banana ConstBanana;
    Banana &amp;&amp;banana1 = ConstBanana(); //<SPAN style="font-family:Times;font-style:italic"> ill-formed</SPAN>
    Banana &amp;&amp;banana2 = Enigma();      //<SPAN style="font-family:Times;font-style:italic"> ill-formed</SPAN>
  }</SPAN>

  const double&amp; rcd2 = 2;             //<SPAN style="font-family:Times;font-style:italic"> </SPAN>rcd2<SPAN style="font-family:Times;font-style:italic"> refers to temporary with value </SPAN>2.0
  ...
</PRE>

<LI><P>Change 13.3.1.4 [over.match.copy] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

Under the conditions specified in 8.5 [dcl.init], as part of a
copy-initialization of an object of class type, a user-defined conversion
can be invoked to convert an initializer expression to the type of the
object being initialized.  Overload resolution is used to select the
user-defined conversion to be invoked. <SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I> The conversion
performed for indirect binding to a reference to a possibly cv-qualified
class type is determined in terms of a corresponding non-reference
copy-initialization. &#8212;<I>end note</I>]</SPAN> Assuming that

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1764"></A><H4>1764.
  
Hiding of function from using-declaration by signature
</H4><B>Section: </B>10.2&#160; [class.member.lookup]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Canada
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-23<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA6">N3690 comment
  CA&#160;6<BR></A>

<P>According to 7.3.3 [namespace.udecl] paragraph 15,</P>

<BLOCKQUOTE>

When a <I>using-declaration</I> brings names from a base class into a
derived class scope, member functions and member function templates in the
derived class override and/or hide member functions and member function
templates with the same name, parameter-type-list
(8.3.5 [dcl.fct]), cv-qualification, and <I>ref-qualifier</I>
(if any) in a base class (rather than conflicting).

</BLOCKQUOTE>

<P>The algorithm for class-scope name lookup given in
10.2 [class.member.lookup], however, does not implement this requirement;
there is nothing that removes a hidden base class member (replacing
the <I>using-declaration</I>, per paragraph 3) from the result set.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change 10.2 [class.member.lookup] paragraph 3 as follows:</P>

<BLOCKQUOTE>

The <I>lookup set</I> for <TT>f</TT> in <TT>C</TT>, called <I>S(f, C)</I>,
consists of two component sets: the <I>declaration set</I>, a set of
members named <TT>f</TT>; and the <I>subobject set</I>, a set of subobjects
where declarations of these members (possibly
including <I>using-declaration</I>s) were found. In the declaration
set, <I>using-declaration</I>s are replaced by the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">members they
designate</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">set of designated members that are not hidden or
overridden by members of the derived class
(7.3.3 [namespace.udecl])</SPAN>, and type declarations (including
injected-class-names) are replaced by the types they designate...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1344"></A><H4>1344.
  
Adding new special member functions to a class via default arguments
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Sean Hunt
 &#160;&#160;&#160;

 <B>Date: </B>2011-08-16<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA29">N3690 comment
  CA&#160;29<BR></A>



<P>If default arguments added in the out-of-class definition of a
constructor make it a special member function, this can affect the
overload resolution and thus the implicit exception specification and
the triviality of an implicitly-declared special member function in
a derived class.</P>

<P>See also <A HREF="
     cwg_active.html#1496">issue 1496</A>, which should also
be addressed by the resolution of this issue.</P>

<P><B>Notes from the September, 2013 meeting:</B></P>

<P>It was decided to resolve this issue separately from
<A HREF="
     cwg_active.html#1496">issue 1496</A>, which is now decoupled from
this issue.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<OL><LI><P>Change 8.3.6 [dcl.fct.default] paragraph 6 as follows:</P></LI>

<BLOCKQUOTE>

Except for member functions of class templates, the default arguments in a
member function definition that appears outside of the class definition are
added to the set of default arguments provided by the member function
declaration in the class definition<SPAN style="font-weight:bold;background-color:#A0FFA0">; the program is ill-formed if a
default constructor (12.1 [class.ctor]), copy or move constructor,
or copy or move assignment operator (12.8 [class.copy]) is so
declared</SPAN>. Default arguments for a member function of a class template
shall be specified on the initial declaration of the member function within
the class template. [<I>Example:</I>...

</BLOCKQUOTE>

<LI><P>Delete the following from 12.8 [class.copy]
paragraph 7:</P></LI>

<BLOCKQUOTE>

<P>...The latter case is deprecated if the class has a user-declared copy
assignment operator or a user-declared destructor. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">Thus, for the class
definition</SPAN></P>

<PRE>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">  struct X {
    X(const X&amp;, int);
  };</SPAN>
</PRE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">a copy constructor is implicitly-declared. If the user-declared
constructor is later defined as</SPAN></P>

<PRE>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">  X::X(const X&amp; x, int i =0) { /* ... */ }</SPAN>
</PRE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">then any use of <TT>X</TT>'s copy constructor is ill-formed because
of the ambiguity; no diagnostic is required.</SPAN></P>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1493"></A><H4>1493.
  
Criteria for move-construction
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2012-04-02<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA23">N3690 comment
  CA&#160;23<BR></A>

<P>The decision in 12.8 [class.copy] paragraph 32 on whether or
not a copy must be replaced by a move is phrased largely in terms of
when copy elision can be performed, as described in the preceding
paragraph.  In particular, the fourth bullet of paragraph 31 applies</P>

<BLOCKQUOTE>

when the <I>exception-declaration</I> of an exception handler (Clause
15 [except]) declares an object of the same type (except
for cv-qualification) as the exception object (15.1 [except.throw]), the copy/move operation can be omitted by treating the
<I>exception-declaration</I> as an alias for the exception object if
the meaning of the program will be unchanged except for the execution
of constructors and destructors for the object declared by the
<I>exception-declaration</I>.

</BLOCKQUOTE>

<P>The determination of &#8220;when the meaning of the program will be
unchanged&#8221; is, in the general case, not practical.  Copy elision
is optional, meaning that the compiler can simply choose not to
perform it if the determination is too difficult.  Choosing whether
to do a copy or a move, however, is mandatory, even if the copy is elided,
and such a broad criterion is not appropriate.  Probably the best way
to address this problem would be to eliminate <I>exception-declaration</I>s
as a possible target for move-construction.</P>

<P>(See also <A HREF="
     cwg_active.html#1579">issue 1579</A>.)</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change 12.8 [class.copy] paragraphs 31 and 32 as follows:</P>

<BLOCKQUOTE>

<P>...This elision of copy/move operations, called copy elision, is
permitted in the following circumstances (which may be combined to
eliminate multiple copies):</P>

<UL><LI><P>...</P></LI>

<LI>

<P>when the <I>exception-declaration</I> of an exception handler (Clause
15 [except]) declares an object of the same type (except for
cv-qualification) as the exception object (15.1 [except.throw]), the
copy<SPAN style="text-decoration:line-through;background-color:#FFA0A0">/move</SPAN> operation can be omitted by treating
the <I>exception-declaration</I> as an alias for the exception object if
the meaning of the program will be unchanged except for the execution of
constructors and destructors for the object declared by
the <I>exception-declaration</I>. <SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I> there cannot be a
move from the exception object because it is always an lvalue.
&#8212;<I>end note</I>]</SPAN></P></LI>

</UL>

<P>[<I>Example:</I>...</P>

<P>When the criteria for elision of a copy<SPAN style="font-weight:bold;background-color:#A0FFA0">/move</SPAN> operation are
met<SPAN style="font-weight:bold;background-color:#A0FFA0">, but not for an <I>exception-declaration</I>,</SPAN> or would be
met save for the fact that the source object is a function parameter, and
the object to be copied is designated by an lvalue, overload resolution to
select the constructor for the copy is first performed as if the object
were designated by an rvalue. If <SPAN style="font-weight:bold;background-color:#A0FFA0">the first</SPAN> overload resolution
fails <SPAN style="font-weight:bold;background-color:#A0FFA0">or was not performed</SPAN>, or if the type of the first
parameter of the selected constructor is not an rvalue reference to the
object's type (possibly cv-qualified), overload resolution is performed
again, considering the object as an lvalue. [<I>Note:</I>...</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1579"></A><H4>1579.
  
Return by converting move constructor
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jeffrey Yasskin
 &#160;&#160;&#160;

 <B>Date: </B>2012-10-23<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#US13">N3690 comment
  US&#160;13<BR></A>



<P>Currently the conditions for moving from an object returned from a
function are tied closely to the criteria for copy elision, which
requires that the type of the object being returned be the same as the
return type of the function.  Another possibility that should be
considered is to allow something like</P>

<PRE>
  optional&lt;T&gt; foo() {
    T t;
    ...
    return t;
  }
</PRE>

<P>and allow <TT>optional&lt;T&gt;::optional(T&amp;&amp;)</TT> to be
used for the initialization of the return type.  Currently this can
be achieved explicitly by use of <TT>std::move</TT>, but it would be
nice not to have to remember to do so.</P>

<P>Similarly, the current rules apply only to complete objects; it
could make sense to allow moving from subobjects of local objects.</P>

<P>(See also <A HREF="
     cwg_active.html#1493">issue 1493</A> for other questions
about the criteria for moving from a returned object.)</P>

<P><B>Rationale (April, 2013):</B></P>

<P>CWG felt that this suggestion should be considered in a broader context
and was thus more appropriate for EWG.</P>

<P><B>Additional note (September, 2013):</B></P>

<P>Returned to "open" status in light of CD National Body comment.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change 12.8 [class.copy] paragraph 32 as follows:</P>

<BLOCKQUOTE>

When the criteria for elision of a copy operation are met <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or would be
met save for the fact that the source object is a function parameter,</SPAN>
and the object to be copied is designated by an lvalue, <SPAN style="font-weight:bold;background-color:#A0FFA0">or when
the <I>expression</I> in a <TT>return</TT> statement is a (possibly
parenthesized) <I>id-expression</I> that names an object with automatic
storage duration declared in the body
or <I>parameter-declaration-clause</I> of the innermost enclosing function
or <I>lambda-expression</I>,</SPAN> overload resolution to select the
constructor for the copy is first performed as if the object were
designated by an rvalue. If overload resolution fails...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1762"></A><H4>1762.
  
Reserved identifier used in <I>literal-operator-id</I> example
</H4><B>Section: </B>13.5.8&#160; [over.literal]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Switzerland
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-23<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CH6">N3690 comment
  CH&#160;6<BR></A>

<P>The example in 13.5.8 [over.literal] paragraph 8 contains
the line</P>

<PRE>
  float operator ""E(const char*); //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
</PRE>

<P><TT>E</TT> does not begin with an underscore and thus is a reserved
name.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change the example in 13.5.8 [over.literal] paragraph 8 as
follows:</P>

<PRE>
  void operator "" _km(long double);                     //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
  string operator "" _i18n(const char*, std::size_t);    //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
  template &lt;char...&gt; double operator "" _\u03C0();       //<SPAN style="font-family:Times;font-style:italic"> OK: UCN for lowercase pi</SPAN>
  float operator ""<SPAN style="font-weight:bold;background-color:#A0FFA0">_</SPAN>E(const char*);                      //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  float operator ""E(const char*);                       //<SPAN style="font-family:Times;font-style:italic"> error: reserved identifier</SPAN></SPAN>
  float operator " " B(const char*);                     //<SPAN style="font-family:Times;font-style:italic"> error: non-empty string-literal</SPAN>
  string operator "" 5X(const char*, std::size_t);       //<SPAN style="font-family:Times;font-style:italic"> error: invalid literal suffix identifier</SPAN>
  double operator "" _miles(double);                     //<SPAN style="font-family:Times;font-style:italic"> error: invalid parameter-declaration-clause</SPAN>
  template &lt;char...&gt; int operator "" _j(const char*);    //<SPAN style="font-family:Times;font-style:italic"> error: invalid parameter-declaration-clause</SPAN>
</PRE>

<BR><BR><HR><A NAME="1770"></A><H4>1770.
  
Type matching of non-type template parameters and arguments
</H4><B>Section: </B>14.8.2.5&#160; [temp.deduct.type]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Canada
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-24<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA15">N3690 comment
  CA&#160;15<BR></A>

<P>According to 14.8.2.5 [temp.deduct.type] paragraph 17,</P>

<BLOCKQUOTE>

If, in the declaration of a function template with a
non-type <I>template-parameter</I>, the non-type <I>template-parameter</I>
is used in an expression in the function parameter-list and, if the
corresponding <I>template-argument</I> is deduced,
the <I>template-argument</I> type shall match the type of
the <I>template-parameter</I> exactly, except that
a <I>template-argument</I> deduced from an array bound may be of any
integral type.

</BLOCKQUOTE>

<P>This does not cover return types, leaving the outcome of an example
like the following unclear:</P>

<PRE>
  template &lt;int N&gt; struct A; 

  template &lt;short N&gt; 
  A&lt;N&gt; *foo(); 

  void bar() { 
    A&lt;1&gt; *(*fp)(void) = &amp;foo; 
  } 
</PRE>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change 14.8.2.5 [temp.deduct.type] paragraph 17 as follows:</P>

<BLOCKQUOTE>

If<SPAN style="text-decoration:line-through;background-color:#FFA0A0">, in the declaration of a function template with a
non-type <I>template-parameter</I>, the non-type <I>template-parameter</I>
is used in an expression in the function parameter-list and, if the
corresponding <I>template-argument</I> is deduced,
the <I>template-argument</I> type shall match the type of
the <I>template-parameter</I> exactly, except that
a <I>template-argument</I> deduced from an array bound may be of any
integral type</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>P</TT> has a form that
contains <TT>&lt;i&gt;</TT>, and if the type of the corresponding value
of <TT>A</TT> differs from the type of <TT>i</TT>, deduction
fails. If <TT>P</TT> has a form that contains <TT>[i]</TT>, and if the type
of <TT>i</TT> is not an integral type, deduction fails</SPAN>.<SUP>147</SUP>
[<I>Example:</I>...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1740"></A><H4>1740.
  
Disambiguation of <TT>noexcept</TT>
</H4><B>Section: </B>15.4&#160; [except.spec]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-08-13<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA27">N3690 comment
  CA&#160;27<BR></A>



<P>There is an ambiguity between a <TT>noexcept</TT> specifier's
optional parenthesized <I>constant-expression</I> and an initializer:</P>

<PRE>
  void f() noexcept;
  void (*p)() noexcept (&amp;f);
</PRE>

<P>Here, we can just about make 8.2 [dcl.ambig.res] paragraph 1's rule
fit, and say that the <TT>(&amp;f)</TT> is part of the
<I>exception-specification</I> rather than being an initializer.  However,
this case is much more problematic:</P>

<PRE>
  void (*fp2)() noexcept, (*fp)() noexcept (fp2 = 0);
</PRE>

<P>The <TT>(fp = 0)</TT> here is unambiguously an initializer, because an
<I>assignment-expression</I> cannot syntactically be
a <I>constant-expression</I>, although current implementations treat it
as an ill-formed part of the <I>exception-specification</I>.</P>

<P>Probably the best approach would be to change 15.4 [except.spec]
to say that a <TT>(</TT> following <TT>noexcept</TT> is always treated
as being part of the <I>noexcept-specification</I>.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change 15.4 [except.spec] paragraph 1 as follows:</P>

<BLOCKQUOTE>

...In a <I>noexcept-specification</I>, the <I>constant-expression</I>, if
supplied, shall be a constant expression (5.19 [expr.const]) that
is contextually converted to bool (Clause 4 [conv]). A
<I>noexcept-specification</I> <TT>noexcept</TT> is equivalent
to <TT>noexcept(<SPAN style="text-decoration:line-through;background-color:#FFA0A0"> </SPAN>true)</TT>. <SPAN style="font-weight:bold;background-color:#A0FFA0">A <TT>(</TT> token that follows
<TT>noexcept</TT> is part of the <I>noexcept-specification</I> (and does
not commence an <I>initializer</I> (8.5 [dcl.init]).</SPAN>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1675"></A><H4>1675.
  
Size limit for automatic array object
</H4><B>Section: </B>B&#160; [implimits]
 &#160;&#160;&#160;

 <B>Status: </B>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2013-05-03<BR>




<P>8.3.4 [dcl.array] paragraph 1 says,</P>

<BLOCKQUOTE>

<P>The expression is <I>erroneous</I> if:</P>

<UL><LI><P>...</P></LI>

<LI><P>its value is such that the size of the allocated object would exceed
the implementation-defined limit (Annex B [implimits]);</P></LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<P>The only relevant limit in B [implimits] is that
of the size of an object, but presumably an implementation might want
to impose a smaller limit on a stack-based object.  This separate
quantity is referred to in paragraph 4 when describing an array of
unspecified bound:</P>

<BLOCKQUOTE>

If the size of the array exceeds the size of the memory available for
objects with automatic storage duration, the behavior is undefined.

</BLOCKQUOTE>

<P>but perhaps it needs to be mentioned in B [implimits] as
well.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>This issue is resolved by the resolution of
<A HREF="
     cwg_active.html#1761">issue 1761</A>.</P>

<BR><BR><BR><BR><HR><A NAME="Tentatively Ready Status"></A><H3>Issues with "Tentatively Ready" Status</H3>
<HR><A NAME="1611"></A><H4>1611.
  
Deleted default constructor for abstract class
</H4><B>Section: </B>12.1&#160; [class.ctor]
 &#160;&#160;&#160;

 <B>Status: </B>tentatively ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Ville Voutilainen
 &#160;&#160;&#160;

 <B>Date: </B>2013-01-31<BR>




<P>Bullet 6 of 12.1 [class.ctor] paragraph 5 gives an abstract
class a deleted default constructor when the virtual base has no default
constructor, even though the abstract class's default constructor can never
construct the virtual base class subobject.  This seems parallel to the
case described in <A HREF="
     cwg_defects.html#257">issue 257</A>
for <I>mem-initializer</I>s.  Should a similar accommodation be made to
avoid deleted default constructors in abstract classes?</P>

<P><B>Notes from the April, 2013 meeting:</B></P>

<P>CWG agreed that a virtual base class should not cause an abstract
class's default constructor to be defined as deleted.</P>

<P><B>Proposed resolution (August, 2013):</B></P>

<P>Change 12.1 [class.ctor] paragraph 4 as follows:</P>

<BLOCKQUOTE>

<P>...A defaulted default constructor for class <TT>X</TT> is defined as
deleted if:</P>

<UL><LI><P>...</P></LI>

<LI><P>any <SPAN style="text-decoration:line-through;background-color:#FFA0A0">direct or virtual base class, or</SPAN> non-static data
member with no <I>brace-or-equal-initializer</I>, <SPAN style="font-weight:bold;background-color:#A0FFA0">or any direct base
class, or, if <TT>X</TT> is not abstract, any virtual base class,</SPAN> has
class type <TT>M</TT> (or array thereof) and either <TT>M</TT> has no
default constructor or overload resolution (13.3 [over.match]) as
applied to <TT>M</TT>'s default constructor results in an ambiguity or in a
function that is deleted or inaccessible from the defaulted default
constructor, or</P></LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<BR><BR><BR><BR><HR><A NAME="Review Status"></A><H3>Issues with "Review" Status</H3>
<HR><A NAME="1614"></A><H4>1614.
  
Address of pure virtual function vs odr-use
</H4><B>Section: </B>3.2&#160; [basic.def.odr]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-01-31<BR>


<P>According to 3.2 [basic.def.odr] paragraph 3,</P>

<BLOCKQUOTE>

A function whose name appears as a potentially-evaluated expression is
odr-used if it is the unique lookup result or the selected member of a set
of overloaded functions (3.4 [basic.lookup],
13.3 [over.match], 13.4 [over.over]), unless it is a pure
virtual function and its name is not explicitly qualified.

</BLOCKQUOTE>

<P>In the following example, consequently, <TT>S::f</TT> is odr-used but
not defined, and (because it is an undefined odr-used inline function) a
diagnostic is required:</P>

<PRE>
  namespace {
    struct S {
      inline virtual void f() = 0;
    };
   void (S::*p) = &amp;S::f;
  }
</PRE>

<P>However, <TT>S::f</TT> cannot be called through such a
pointer-to-member, so forming a pointer-to-member should not
cause a pure virtual function to be odr-used.  There is
implementation divergence on this point.</P>

<P><B>Proposed resolution (April, 2013):</B></P>

<P>Change 3.2 [basic.def.odr] paragraph 3 as follows:</P>

<BLOCKQUOTE>

...A virtual member function is odr-used if it is not pure. A function
whose name appears as a potentially-evaluated expression is odr-used if it
is the unique lookup result or the selected member of a set of overloaded
functions (3.4 [basic.lookup], 13.3 [over.match],
13.4 [over.over]), unless it is a pure virtual function and
<SPAN style="font-weight:bold;background-color:#A0FFA0">either</SPAN> its name is not explicitly qualified <SPAN style="font-weight:bold;background-color:#A0FFA0">or the
expression forms a pointer to member (5.3.1)</SPAN>. [<I>Note:</I>...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1603"></A><H4>1603.
  
Errors resulting from giving unnamed namespaces internal linkage
</H4><B>Section: </B>3.5&#160; [basic.link]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-01-09<BR>




<P>In C++03, all namespace-scope names had external linkage unless
explicitly declared otherwise (via <TT>static</TT>, <TT>const</TT>,
or as a member of an anonymous union).  C++11 now specifies that members
of an unnamed namespace have internal linkage (see
<A HREF="
     cwg_defects.html#1113">issue 1113</A>).  This change invalidated a
number of assumptions scattered throughout the Standard that need to
be adjusted:</P>

<OL><LI><P>3.5 [basic.link] paragraph 5 says,</P></LI>

<BLOCKQUOTE>

a member function, static data member, a named class or enumeration of
class scope, or an unnamed class or enumeration defined in a
class-scope typedef declaration such that the class or enumeration has
the typedef name for linkage purposes (7.1.3 [dcl.typedef]),
has external linkage if the name of the class has external linkage.

</BLOCKQUOTE>

<P>There is no specification for the linkage of such members of a class
with internal linkage.  Formally, at least, that leads to the statement
in paragraph 8 that such members have no linkage.  This omission also
contradicts the note in 9.3 [class.mfct] paragraph 3:</P>

<BLOCKQUOTE>

[<I>Note:</I> Member functions of a class in namespace scope have
external linkage.  Member functions of a local class (9.8 [class.local]) have no linkage. See 3.5 [basic.link].
&#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>as well as the statement in 9.4.2 [class.static.data] paragraph
5,</P>

<BLOCKQUOTE>

<TT>Static</TT> data members of a class in namespace scope have external
linkage (3.5 [basic.link]).

</BLOCKQUOTE>

<LI><P>The footnote in 3.5 [basic.link] paragraph 8 says,</P></LI>

<BLOCKQUOTE>

A class template always has external linkage, and the requirements of
14.3.1 [temp.arg.type] and 14.3.2 [temp.arg.nontype] ensure
that the template arguments will also have appropriate linkage.

</BLOCKQUOTE>

<P>This is incorrect, since templates in unnamed namespaces now have
internal linkage and template arguments are no longer required to have
external linkage.</P>

<LI><P>The statement in 7.1.1 [dcl.stc] paragraph 7 is now
false:</P></LI>

<BLOCKQUOTE>

A name declared in a namespace scope without a
<I>storage-class-specifier</I> has external linkage unless it has
internal linkage because of a previous declaration and provided it is
not declared <TT>const</TT>.

</BLOCKQUOTE>

<LI><P>The entire treatment of <I>unique</I> in 7.3.1.1 [namespace.unnamed]
is no longer necessary, and the footnote is incorrect:</P></LI>

<BLOCKQUOTE>

Although entities in an unnamed namespace might have external linkage,
they are effectively qualified by a name unique to their translation
unit and therefore can never be seen from any other translation unit.

</BLOCKQUOTE>

<P>Names in unnamed namespaces never have external linkage.</P>

<LI><P>According to 11.3 [class.friend] paragraph 4,</P></LI>

<BLOCKQUOTE>

A function first declared in a friend declaration has external linkage
(3.5 [basic.link]).

</BLOCKQUOTE>

<P>This presumably is incorrect for a class that is a member of an
unnamed namespace.</P>

<LI><P>According to 14 [temp] paragraph 4,</P></LI>

<BLOCKQUOTE>

A non-member function template can have internal linkage; any other
template name shall have external linkage.

</BLOCKQUOTE>

<P>Taken literally, this would mean that a template could not be a
member of an unnamed namespace.</P>

</OL>

<P><B>Proposed resolution (April, 2013):</B></P>

<OL><LI><P>Change 3.5 [basic.link] paragraph 5 as follows:</P></LI>

<BLOCKQUOTE>

In addition, a member function, static data member, a named class or
enumeration of class scope, or an unnamed class or enumeration defined in a
class-scope typedef declaration such that the class or enumeration has the
typedef name for linkage purposes (7.1.3 [dcl.typedef]),
has <SPAN style="text-decoration:line-through;background-color:#FFA0A0">external linkage if the name of the class has external
linkage</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">the same linkage, if any, as the name of the class of
which it is a member.</SPAN>.

</BLOCKQUOTE>

<LI><P>Change the footnote in 3.5 [basic.link] paragraph 8 as
follows:</P></LI>

<BLOCKQUOTE>

33) A class template <SPAN style="text-decoration:line-through;background-color:#FFA0A0">always has external linkage, and the requirements
of 14.3.1 [temp.arg.type] and 14.3.2 [temp.arg.nontype] ensure that
the template arguments will also have appropriate linkage</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">has
the linkage of the innermost enclosing class or namespace in which it is
declared</SPAN>.

</BLOCKQUOTE>

<LI><P>Change 7.1.1 [dcl.stc] paragraph 7 as follows:</P></LI>

<BLOCKQUOTE>

A name declared in a namespace scope without
a <I>storage-class-specifier</I> has <SPAN style="text-decoration:line-through;background-color:#FFA0A0">external linkage</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">the
same linkage as the namespace</SPAN> unless it has internal linkage because
of a previous declaration and provided it is not declared const.

</BLOCKQUOTE>

<LI><P>Change 7.3.1.1 [namespace.unnamed] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<P>An <I>unnamed-namespace-definition</I> behaves as if it were replaced
by</P>

<PRE>
  inline<SUB><SPAN style="font-family:Times;font-style:italic">opt</SPAN></SUB> namespace <SPAN style="font-family:Times;font-style:italic">unique</SPAN> { /* empty body */ }
  using namespace <SPAN style="font-family:Times;font-style:italic">unique</SPAN> ;
  namespace <SPAN style="font-family:Times;font-style:italic">unique</SPAN> { <SPAN style="font-family:Times;font-style:italic">namespace-body</SPAN> }
</PRE>

<P>where <TT>inline</TT> appears if and only if it appears in
the <I>unnamed-namespace-definition</I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">,</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">and</SPAN> all
occurrences of <I>unique</I> in a translation unit are replaced by the same
identifier<SPAN style="font-weight:bold;background-color:#A0FFA0">.</SPAN><SPAN style="text-decoration:line-through;background-color:#FFA0A0">, and this identifier differs from all other
identifiers in the entire program. [<I>Footnote:</I> Although entities in
an unnamed namespace might have external linkage, they are effectively
qualified by a name unique to their translation unit and therefore can
never be seen from any other translation unit. &#8212;<I>end
footnote</I>]</SPAN> [<I>Example:</I>...</P>

</BLOCKQUOTE>

<LI><P>Change the note in 9.3 [class.mfct] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

[<I>Note:</I> Member functions of a class in namespace scope
have <SPAN style="text-decoration:line-through;background-color:#FFA0A0">external linkage</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">the linkage of that class</SPAN>.
Member functions of a local class (9.8 [class.local]) have no linkage. See
3.5 [basic.link]. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<LI><P>Change 9.4.2 [class.static.data] paragraph 5 as follows:</P></LI>

<BLOCKQUOTE>

<TT>Static</TT> data members of a class in namespace scope
have <SPAN style="text-decoration:line-through;background-color:#FFA0A0">external linkage</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">the linkage of that class</SPAN>
(3.5 [basic.link]).

</BLOCKQUOTE>

<LI><P>Change 11.3 [class.friend] paragraph 4 as follows:</P></LI>

<BLOCKQUOTE>

A function first declared in a friend declaration has <SPAN style="text-decoration:line-through;background-color:#FFA0A0">external
linkage</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">the linkage of the namespace of which it is a
member</SPAN> (3.5 [basic.link]). Otherwise, the function retains
its previous linkage (7.1.1 [dcl.stc]).

</BLOCKQUOTE>

<LI><P>Change 14 [temp] paragraph 4 as follows:</P></LI>

<BLOCKQUOTE>

A template name has linkage (3.5 [basic.link]). <SPAN style="text-decoration:line-through;background-color:#FFA0A0">A non-member
function template can have internal linkage; any other template name shall
have external linkage.</SPAN> Specializations (explicit or implicit) of a
template that has internal linkage are distinct from all specializations in
other translation units...

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1686"></A><H4>1686.
  
Which variables are &#8220;explicitly declared <TT>const</TT>?&#8221;
</H4><B>Section: </B>3.5&#160; [basic.link]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2013-05-17<BR>




<P>According to 3.5 [basic.link] paragraph 3,</P>

<BLOCKQUOTE>

<P>A name having namespace scope (3.3.6 [basic.scope.namespace]) has internal
linkage if it is the name of</P>

<UL><LI><P>...</P></LI>

<LI><P>a non-volatile variable that is explicitly declared <TT>const</TT> or
<TT>constexpr</TT> and neither explicitly declared <TT>extern</TT> nor
previously declared to have external linkage; or</P></LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<P>It would be more precise and less confusing if the phrase
&#8220;explicitly declared <TT>const</TT>&#8221; were replaced by saying
that its type is const-qualified.  This change would also allow
removal of the reference to <TT>constexpr</TT>, which was added by
<A HREF="
     cwg_defects.html#1112">issue 1112</A> because <TT>constexpr</TT>
variables are implicitly const-qualified but not covered by
the &#8220;explicitly declared&#8221; phrasing.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change the second bullet of 3.5 [basic.link] paragraph 3 as
follows:</P>

<UL><LI><P>a <SPAN style="text-decoration:line-through;background-color:#FFA0A0">non-volatile</SPAN> variable <SPAN style="text-decoration:line-through;background-color:#FFA0A0">that is explicitly
declared <TT>const</TT> or <TT>constexpr</TT> and</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">of
non-volatile const-qualified type that is</SPAN> neither explicitly
declared <TT>extern</TT> nor previously declared to have external linkage;
or</P></LI></UL>

<BR><BR><HR><A NAME="1465"></A><H4>1465.
  
<TT>noexcept</TT> and <TT>std::bad_array_new_length</TT>
</H4><B>Section: </B>5.3.7&#160; [expr.unary.noexcept]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2012-02-12<BR>




<P>The list of causes for a <TT>false</TT> result of the <TT>noexcept</TT>
operator does not include a <I>new-expression</I> with a non-constant
array bound, which could result in an exception even if the allocation
function that would be called is declared not to throw (see
5.3.4 [expr.new] paragraph 7).</P>

<P><B>Proposed resolution (October, 2012):</B></P>

<P>This issue is resolved by the resolution of
<A HREF="
     cwg_active.html#1351">issue 1351</A>.</P>

<BR><BR><HR><A NAME="1685"></A><H4>1685.
  
Value category of <TT>noexcept</TT> expression
</H4><B>Section: </B>5.3.7&#160; [expr.unary.noexcept]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2013-05-16<BR>




<P>According to 5.3.7 [expr.unary.noexcept] paragraph 2,</P>

<BLOCKQUOTE>

The result of the <TT>noexcept</TT> operator is a constant of
type <TT>bool</TT> and is an rvalue.

</BLOCKQUOTE>

<P>Obviously, the result should be a prvalue.</P>

<P>(See also <A HREF="
     cwg_active.html#1642">issue 1642</A>, which deals with
missing specifications of value categories.)</P>

<P><B>Notes from the September, 2013 meeting:</B></P>

<P>This issue is being handled editorially and is being placed in
"review" status to ensure that the change has been made.</P>

<BR><BR><HR><A NAME="1596"></A><H4>1596.
  
Non-array objects as <TT>array[1]</TT>
</H4><B>Section: </B>5.9&#160; [expr.rel]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2012-12-20<BR>




<P>The provision to treat non-array objects as if they were array
objects with a bound of 1 is given only for pointer arithmetic in C++
(5.7 [expr.add] paragraph 4).  C99 supplies similar wording
for the relational and equality operators, explicitly allowing
pointers resulting from such implicit-array treatment to be compared.
C++ should follow suit.</P>

<P><B>Proposed resolution (August, 2013):</B></P>

<OL><LI><P>Change 5.3.1 [expr.unary.op] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

<P>...Otherwise, if the type of the expression is <TT>T</TT>, the result
has type &#8220;pointer to <TT>T</TT>&#8221; and is a prvalue that is the
address of the designated object (1.7 [intro.memory]) or a pointer to
the designated function. [<I>Note:</I> In particular, the address of an
object of type &#8220;<I>cv</I> <TT>T</TT>&#8221; is &#8220;pointer
to <I>cv</I> <TT>T</TT>&#8221;, with the same cv-qualification.
&#8212;<I>end note</I>] <SPAN style="font-weight:bold;background-color:#A0FFA0">For purposes of pointer arithmetic
(5.7 [expr.add]) and comparison (5.9 [expr.rel],
5.10 [expr.eq]), an object that is not an array element whose
address is taken in this way is considered to belong to an array with one
element of type <TT>T</TT>.</SPAN> [<I>Example:</I></P>

<PRE>
  struct A { int i; };
  struct B : A { };
  ... &amp;B::i ...        //<SPAN style="font-family:Times;font-style:italic"> has type </SPAN>int A::*
<SPAN style="font-weight:bold;background-color:#A0FFA0">  int a;
  int* p1 = &amp;a;
  int* p2 = p1 + 1;    //<SPAN style="font-family:Times;font-style:italic"> Defined behavior</SPAN>
  bool b = p2 &gt; p1;    //<SPAN style="font-family:Times;font-style:italic"> Defined behavior, with value </SPAN>true</SPAN>
</PRE>

<P>&#8212;<I>end example</I>] [<I>Note:</I> a pointer to member...</P>

</BLOCKQUOTE>

<LI><P>Delete 5.7 [expr.add] paragraph 4:</P></LI>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">For the purposes of these operators, a pointer to a nonarray object
behaves the same as a pointer to the first element of an array of length
one with the type of the object as its element type.</SPAN>

</BLOCKQUOTE>

<LI><P>Change 5.7 [expr.add] paragraph 5 as follows:</P></LI>

<BLOCKQUOTE>

When an expression that has integral type is added to or subtracted from a
pointer, the result has the type of the pointer operand. If the pointer
operand points to an element of an array object <SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Footnote:</I> An
object that is not an array element is considered to belong to a
single-element array for this purpose; see 5.3.1 [expr.unary.op]
&#8212;<I>end footnote</I>]</SPAN>, and the array is large enough, the
result points to an element

</BLOCKQUOTE>

<LI><P>Change 5.9 [expr.rel] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

Comparing pointers to objects <SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Footnote:</I> An object that is not
an array element is considered to belong to a single-element array for this
purpose; see 5.3.1 [expr.unary.op] &#8212;<I>end footnote</I>]</SPAN>
is defined as follows:...

</BLOCKQUOTE>

</OL>

<P><I>[Drafting note: No change is proposed for 5.10 [expr.eq],
since the comparison is phrased in terms of &#8220;same address&#8221;, not
in terms of array elements, so the handling of one-past-the-end addresses
falls out of the specification of pointer arithmetic.]</I></P>

<BR><BR><HR><A NAME="1683"></A><H4>1683.
  
Incorrect example after <TT>constexpr</TT> changes
</H4><B>Section: </B>5.19&#160; [expr.const]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2013-05-15<BR>


<P>The example in 5.19 [expr.const] paragraph 6,</P>

<PRE>
  struct A {
    constexpr A(int i) : val(i) { }
    constexpr operator int() { return val; }
    constexpr operator long() { return 43; }
  private:
    int val;
  };
  template&lt;int&gt; struct X { };
  constexpr A a = 42;
  X&lt;a&gt; x;               //<SPAN style="font-family:Times;font-style:italic"> OK: unique conversion to </SPAN>int
  int ary[a];           //<SPAN style="font-family:Times;font-style:italic"> error: ambiguous conversion</SPAN>
</PRE>

<P>is no longer correct now that <TT>constexpr</TT> does not imply
<TT>const</TT> for member functions, since the conversion functions
cannot be invoked for the constant <TT>a</TT>.</P>

<P><B>Notes from the September, 2013 meeting:</B></P>

<P>This issue is being handled editorially and is being placed in
"review" status to ensure that the change has been made.</P>

<BR><BR><HR><A NAME="1694"></A><H4>1694.
  
Restriction on reference to temporary as a constant expression
</H4><B>Section: </B>5.19&#160; [expr.const]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-05-30<BR>




<P>We're missing a restriction on the value of a temporary which is bound
to a static storage duration reference:</P>

<PRE>
  void f(int n) {
    static constexpr int *&amp;&amp;r = &amp;n;
  }
</PRE>

<P>This is currently valid, because <TT>&amp;n</TT> is a core constant
expression, and it is a constant expression because the reference binds to
a temporary (of type <TT>int*</TT>) that has static storage duration
(because it's lifetime-extended by the reference binding).</P>

<P>The value of <TT>r</TT> <I>is</I> constant here (it's a constant
reference to a temporary with a non-constant initializer), but I don't
think we should accept this. Generally, I think a temporary which is
lifetime-extended by a constexpr variable should also be treated as if it
were declared to be a constexpr object.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change 5.19 [expr.const] paragraph 4 as follows:</P>

<BLOCKQUOTE>

<P>A <I>constant expression</I> is either a glvalue core constant
expression whose value refers to an <SPAN style="text-decoration:line-through;background-color:#FFA0A0">object with static storage
duration or to a function</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">entity that is a permitted result of a
constant expression</SPAN>, or a prvalue core constant expression whose
value is an object where, for that object and its subobjects:</P>

<UL><LI><P>each non-static data member of reference type refers to an
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">object with static storage duration or to a function</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">entity that is a permitted result of a constant expression</SPAN>,
and</P></LI>

<LI><P>if the object or subobject is of pointer type, it contains the
address of an object with static storage duration, the address past the end
of such an object (5.7 [expr.add]), the address of a function, or
a null pointer value.</P></LI>

</UL>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">An entity is a permitted result of a constant expression if it is
an object with static storage duration that is either not a temporary or is
a temporary whose value satisfies the above constraints, or it is a
function.</SPAN></P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1600"></A><H4>1600.
  
Erroneous reference initialization in example
</H4><B>Section: </B>7.1.6.2&#160; [dcl.type.simple]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Niels Dekker
 &#160;&#160;&#160;

 <B>Date: </B>2012-12-30<BR>




<P>The example in 7.1.6.2 [dcl.type.simple] paragraph 4 reads,
in part,</P>

<PRE>
  const int&amp;&amp; foo();
  int i;
  decltype(foo()) x1 = i; //<SPAN style="font-family:Times;font-style:italic"> type is </SPAN>const int&amp;&amp;
</PRE>

<P>The initialization is an ill-formed attempt to bind an rvalue
reference to an lvalue.</P>

<P><B>Proposed resolution (April, 2013):</B></P>

<P>Change the example in 7.1.6.2 [dcl.type.simple] paragraph 4 as follows:</P>

<PRE>
  const int&amp;&amp; foo();
  int i;
  struct A { double x; };
  const A* a = new A();
  decltype(foo()) x1 = <SPAN style="text-decoration:line-through;background-color:#FFA0A0">i</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">17</SPAN>;     //<SPAN style="font-family:Times;font-style:italic"> type is </SPAN>const int&amp;&amp;
  decltype(i) x2;                //<SPAN style="font-family:Times;font-style:italic"> type is </SPAN>int
  decltype(a-&gt;x) x3;             //<SPAN style="font-family:Times;font-style:italic"> type is </SPAN>double
  decltype((a-&gt;x)) x4 = x3;      //<SPAN style="font-family:Times;font-style:italic"> type is </SPAN>const double&amp;
</PRE>

<BR><BR><HR><A NAME="1615"></A><H4>1615.
  
Alignment of types, variables, and members
</H4><B>Section: </B>7.6.2&#160; [dcl.align]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-02-01<BR>




<P>According to 7.6.2 [dcl.align] paragraph 5,</P>

<BLOCKQUOTE>

The combined effect of all <I>alignment-specifier</I>s in a declaration
shall not specify an alignment that is less strict than the alignment that
would be required for the entity being declared if
all <I>alignment-specifier</I>s were omitted (including those in other
declarations).

</BLOCKQUOTE>

<P>Presumably the intent was &#8220;other declarations of the same
entity,&#8221; but the wording as written could be read to make the
following example well-formed (assuming <TT>alignof(int)</TT> is 4):</P>

<PRE>
  struct alignas(4) A {
    alignas(8) int n;
  };
  struct alignas(8) B {
    char c;
  };
  alignas(1) B b;
  struct alignas(1) C : B {};
  enum alignas(8) E : int { k };
  alignas(4) E e = k;
</PRE>

<P><B>Proposed resolution (April, 2013):</B></P>

<BLOCKQUOTE>

<P>...if all <I>alignment-specifier</I>s <SPAN style="font-weight:bold;background-color:#A0FFA0">appertaining to that
entity</SPAN> were omitted <SPAN style="text-decoration:line-through;background-color:#FFA0A0">(including those in other
declarations</SPAN>. <SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  struct alignas(8) S {};
  struct alignas(1) U {
    S s;
  };   //<SPAN style="font-family:Times;font-style:italic"> Error: </SPAN>U<SPAN style="font-family:Times;font-style:italic"> requires alignment for </SPAN>U<SPAN style="font-family:Times;font-style:italic"> that is less strict than</SPAN>
       //<SPAN style="font-family:Times;font-style:italic"> if the </SPAN>alignas(1)<SPAN style="font-family:Times;font-style:italic"> were omitted.</SPAN></SPAN>
</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end example</I>]</SPAN></P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1633"></A><H4>1633.
  
Copy-initialization in member initialization
</H4><B>Section: </B>8.5&#160; [dcl.init]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Vinny Romano
 &#160;&#160;&#160;

 <B>Date: </B>2013-03-04<BR>




<P>According to 8.5 [dcl.init] paragraph 16,</P>

<BLOCKQUOTE>

<P>The initialization that occurs in the forms</P>

<PRE>
  T x(a);
  T x{a};
</PRE>

<P>as well as in new expressions
(5.3.4 [expr.new]), <TT>static_cast</TT> expressions
(5.2.9 [expr.static.cast]), functional notation type conversions
(5.2.3 [expr.type.conv]), and base and member initializers
(12.6.2 [class.base.init]) is called <I>direct-initialization</I>.</P>

</BLOCKQUOTE>

<P>This wording was overlooked when <I>brace-or-equal-initializer</I>s
were added to the language, permitting copy-initialization of members
by use of the <TT>=</TT> form.</P>

<P><B>Proposed resolution (April, 2013):</B></P>

<P>Change 8.5 [dcl.init] paragraphs 15-16 as follows:</P>

<BLOCKQUOTE>

<P>The initialization that occurs in the form</P>

<PRE>
  T x = a;
</PRE>

<P>as well as in argument passing, function return, throwing an exception
(15.1 [except.throw]), handling an exception
(15.3 [except.handle]), <SPAN style="font-weight:bold;background-color:#A0FFA0">the <TT>=</TT> form of a
<I>brace-or-equal-initializer</I> (12.6.2 [class.base.init]),</SPAN> and
aggregate member initialization (8.5.1 [dcl.init.aggr]) is
called <I>copy-initialization</I>. [<I>Note:</I> Copy-initialization may
invoke a move (12.8). &#8212;<I>end note</I>]</P>

<P>The initialization that occurs in the forms</P>

<PRE>
  T x(a);
  T x{a};
</PRE>

<P>as well as in new expressions
(5.3.4 [expr.new]), <TT>static_cast</TT> expressions (5.2.9),
functional notation type conversions (5.2.3 [expr.type.conv]), and base
and member initializers (12.6.2 [class.base.init]) <SPAN style="font-weight:bold;background-color:#A0FFA0">other than
the <TT>=</TT> form of a <I>brace-or-equal-initializer</I></SPAN> is
called <I>direct-initialization</I>.</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1517"></A><H4>1517.
  
Unclear/missing description of behavior during construction/destruction
</H4><B>Section: </B>12.7&#160; [class.cdtor]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2012-07-07<BR>


<P>The current wording of 12.7 [class.cdtor] paragraph 4 does
not describe the behavior of calling a virtual function in a
<I>mem-initializer</I> for a base class, only for a non-static data
member.  Also, the changes for <A HREF="
     cwg_defects.html#1202">issue 1202</A>
should have been, but were not, applied to the description of the
behavior of <TT>typeid</TT> and <TT>dynamic_cast</TT> in paragraphs 5
and 6.</P>

<P>In addition, the resolution of <A HREF="
     cwg_defects.html#597">issue 597</A>
allowing the out-of-lifetime conversion of pointers/lvalues to
non-virtual base classes, should have been, but were not, applied to
paragraph 3.</P>

<P><B>Proposed resolution (August, 2013):</B></P>

<OL><LI><P>Change 12.7 [class.cdtor] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

For an object with a non-trivial constructor, referring to any
non-static member or <SPAN style="font-weight:bold;background-color:#A0FFA0">virtual</SPAN> base class of the object
before the constructor begins execution results in undefined behavior.
For an object with a non-trivial destructor, referring to any
non-static member or <SPAN style="font-weight:bold;background-color:#A0FFA0">virtual</SPAN> base class of the object after
the destructor finishes execution results in undefined
behavior. [<I>Example:</I>

<PRE>
  struct X { int i; };
  struct Y : X { Y(); };                       //<SPAN style="font-family:Times;font-style:italic"> non-trivial</SPAN>
  struct A { int a; };
  struct B : <SPAN style="text-decoration:line-through;background-color:#FFA0A0">public</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">virtual</SPAN> A { int j; Y y; }; //<SPAN style="font-family:Times;font-style:italic"> non-trivial</SPAN>

  extern B bobj;
  B* pb = &amp;bobj;                               //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
  int* p1 = &amp;bobj.a;                           //<SPAN style="font-family:Times;font-style:italic"> undefined, refers to base class member</SPAN>
  int* p2 = &amp;bobj.y.i;                         //<SPAN style="font-family:Times;font-style:italic"> undefined, refers to member's member</SPAN>

  A* pa = &amp;bobj;                               //<SPAN style="font-family:Times;font-style:italic"> undefined, upcast to a <SPAN style="font-weight:bold;background-color:#A0FFA0">virtual</SPAN> base class type</SPAN>
  B bobj;                                      //<SPAN style="font-family:Times;font-style:italic"> definition of </SPAN>bobj

  extern X xobj;
  int* p3 = &amp;xobj.i;                           //<SPAN style="font-family:Times;font-style:italic">OK, </SPAN>X<SPAN style="font-family:Times;font-style:italic"> is a trivial class</SPAN>
  X xobj;
</PRE>

</BLOCKQUOTE>

<LI><P>Change 12.7 [class.cdtor] paragraphs 3-6 as follows:</P></LI>

<BLOCKQUOTE>

<P>To explicitly or implicitly convert a pointer (a glvalue) referring to
an object of class <TT>X</TT> to a pointer (reference) to a direct or
indirect <SPAN style="font-weight:bold;background-color:#A0FFA0">virtual</SPAN> base class <TT>B</TT> of <TT>X</TT>, the
construction of <TT>X</TT> and the construction of all of its direct or
indirect bases <SPAN style="text-decoration:line-through;background-color:#FFA0A0">that directly or indirectly derive from</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">for which</SPAN> <TT>B</TT> <SPAN style="font-weight:bold;background-color:#A0FFA0">is a direct or indirect virtual
base</SPAN> shall have started and the destruction of these classes
shall not have completed, otherwise the conversion results in
undefined behavior. To form a pointer to (or access the value of) a
direct non-static member...</P>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">Member functions, including virtual functions
(10.3 [class.virtual]), can be called during construction or
destruction (12.6.2 [class.base.init]).  When a virtual function is
called directly or indirectly from a constructor or from a destructor,
including during the construction or destruction of the class's non-static
data members, and the object to which the call applies is the object (call
it <TT>x</TT>) under construction or destruction, the function called is
the final overrider in the constructor's or destructor's class and not one
overriding it in a more-derived class.  If the virtual function call uses
an explicit class member access (5.2.5 [expr.ref]) and the object
expression refers to the complete object of x or one of that object's base
class subobjects but not to <TT>x</TT> or one of its base class subobjects,
the behavior is undefined.</SPAN>

<SPAN style="font-weight:bold;background-color:#A0FFA0">The <I>period of construction</I> of an object or subobject whose type
is a class type <TT>C</TT> begins immediately after the construction of all
its base class subobjects is complete and concludes when the last
constructor of class <TT>C</TT> exits.  The <I>period of destruction</I> of
an object or subobject whose type is a class type <TT>C</TT> begins when
the destructor for <TT>C</TT> begins execution and concludes immediately
before beginning the destruction of its base class
subobjects. A <I>polymorphic operation</I> is a virtual function call
(5.2.2 [expr.call]), the <TT>typeid</TT> operator
(5.2.8 [expr.typeid]) when applied to a glvalue of polymorphic type,
or the <TT>dynamic_cast</TT> operator (5.2.7 [expr.dynamic.cast]) when
applied to a pointer to or glvalue of a polymorphic type. A <I>polymorphic
operand</I> is the object expression in a virtual function call or the
operand of a polymorphic <TT>typeid</TT>
or <TT>dynamic_cast</TT>.</SPAN></P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0"> During the period of construction or period of destruction of
an object or subobject whose type is a class type <TT>C</TT> (call
it <TT>x</TT>), the effect of performing a polymorphic operation in
which the polymorphic operand designates <TT>x</TT> or a base class
subobject thereof is as if the dynamic type of the object were
class <TT>C</TT>.  [<I>Footnote:</I> This is true even if <TT>C</TT>
is an abstract class, which cannot be the type of a most-derived
object. &#8212;<I>end footnote</I>] If a polymorphic operand refers to
an object or subobject having class type <TT>C</TT> before its period
of construction begins or after its period of destruction is complete,
the behavior is undefined. [<I>Note:</I> This includes the evaluation
of an expression appearing in a <I>mem-initializer</I> of <TT>C</TT>
in which the <I>mem-initializer-id</I> designates <TT>C</TT> or one of
its base classes. &#8212;<I>end note</I>]</SPAN> [<I>Example:</I></P>

<PRE>
  struct V {
<SPAN style="font-weight:bold;background-color:#A0FFA0">    V();
    V(int);</SPAN>
    virtual void f();
    virtual void g();
  };

  struct A : virtual V {
    virtual void f();
<SPAN style="font-weight:bold;background-color:#A0FFA0">    virtual int h();
    A() : V(h()) { }     //<SPAN style="font-family:Times;font-style:italic"> undefined behavior: virtual function </SPAN>h<SPAN style="font-family:Times;font-style:italic"> called</SPAN>
                         //<SPAN style="font-family:Times;font-style:italic"> before </SPAN>A<SPAN style="font-family:Times;font-style:italic">'s period of construction begins</SPAN></SPAN>
  };

  struct B : virtual V {
    virtual void g();
    B(V*, A*);
  };

  struct D : A, B {
    virtual void f();
    virtual void g();
    D() : B((A*)this, this) { }
  };

  B::B(V* v, A* a) {
    f();                 //<SPAN style="font-family:Times;font-style:italic"> calls </SPAN>V::f<SPAN style="font-family:Times;font-style:italic">, not </SPAN>A::f
    g();                 //<SPAN style="font-family:Times;font-style:italic"> calls </SPAN>B::g<SPAN style="font-family:Times;font-style:italic">, not </SPAN>D::g
    v-&gt;g();              //<SPAN style="font-family:Times;font-style:italic"> </SPAN>v<SPAN style="font-family:Times;font-style:italic"> is base of </SPAN>B<SPAN style="font-family:Times;font-style:italic">, the call is well-defined, calls </SPAN>B::g
    a-&gt;f();              //<SPAN style="font-family:Times;font-style:italic"> undefined behavior, </SPAN>a<SPAN style="font-family:Times;font-style:italic">'s type not a base of </SPAN>B
<SPAN style="font-weight:bold;background-color:#A0FFA0">    typeid(*this);       //<SPAN style="font-family:Times;font-style:italic"> </SPAN>type_info<SPAN style="font-family:Times;font-style:italic"> for </SPAN>B
    typeid(*v);          //<SPAN style="font-family:Times;font-style:italic"> well-defined: </SPAN>*v<SPAN style="font-family:Times;font-style:italic"> has type </SPAN>V<SPAN style="font-family:Times;font-style:italic">, a base of </SPAN>B<SPAN style="font-family:Times;font-style:italic">,</SPAN>
                         //<SPAN style="font-family:Times;font-style:italic"> so its period of construction is complete;</SPAN>
                         //<SPAN style="font-family:Times;font-style:italic"> yields </SPAN>type_info<SPAN style="font-family:Times;font-style:italic"> for </SPAN>B
    typeid(*a);          //<SPAN style="font-family:Times;font-style:italic"> undefined behavior: </SPAN>A<SPAN style="font-family:Times;font-style:italic"> is not a base of </SPAN>B<SPAN style="font-family:Times;font-style:italic">,</SPAN>
                         //<SPAN style="font-family:Times;font-style:italic"> so its period of construction has not begun</SPAN>
    dynamic_cast&lt;B*&gt;(v); //<SPAN style="font-family:Times;font-style:italic"> well-defined: </SPAN>v<SPAN style="font-family:Times;font-style:italic"> has type </SPAN>V*<SPAN style="font-family:Times;font-style:italic">, </SPAN>V<SPAN style="font-family:Times;font-style:italic"> is a base of </SPAN>B<SPAN style="font-family:Times;font-style:italic">,</SPAN>
                         //<SPAN style="font-family:Times;font-style:italic"> so its period of construction is complete;</SPAN>
                         //<SPAN style="font-family:Times;font-style:italic"> results in </SPAN>this
    dynamic_cast&lt;B*&gt;(a); //<SPAN style="font-family:Times;font-style:italic"> undefined behavior: </SPAN>A<SPAN style="font-family:Times;font-style:italic"> is not a base of </SPAN>B<SPAN style="font-family:Times;font-style:italic">,</SPAN>
                         //<SPAN style="font-family:Times;font-style:italic"> so its period of construction has not begun</SPAN></SPAN>
  }
</PRE>

<P>&#8212;<I>end example</I>]</P>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">The <TT>typeid</TT> operator (5.2.8 [expr.typeid]) can be
used during construction or destruction
(12.6.2 [class.base.init]). When <TT>typeid</TT> is used in a
constructor (including the <I>mem-initializer</I> or
<I>brace-or-equal-initializer</I> for a non-static data member) or in a
destructor, or used in a function called (directly or indirectly) from a
constructor or destructor, if the operand of <TT>typeid</TT> refers to the
object under construction or destruction,
<TT>typeid</TT> yields the <TT>std::type_info</TT> object representing
the constructor or destructor's class. If the operand of
<TT>typeid</TT> refers to the object under construction or destruction
and the static type of the operand is neither the constructor or
destructor's class nor one of its bases, the result of <TT>typeid</TT>
is undefined.</SPAN>
</P>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>dynamic_cast</TT>s (5.2.7 [expr.dynamic.cast]) can be used
during construction or destruction (12.6.2 [class.base.init]).  When
a <TT>dynamic_cast</TT> is used in a constructor (including
the <I>mem-initializer</I> or <I>brace-or-equal-initializer</I> for a
non-static data member) or in a destructor, or used in a function called
(directly or indirectly) from a constructor or destructor, if the operand
of the <TT>dynamic_cast</TT> refers to the object under construction or
destruction, this object is considered to be a most derived object that has
the type of the constructor or destructor's class. If the operand of
the <TT>dynamic_cast</TT> refers to the object under construction or
destruction and the static type of the operand is not a pointer to or
object of the constructor or destructor's own class or one of its bases,
the <TT>dynamic_cast</TT> results in undefined behavior.
[<I>Example:</I></SPAN>
</P>

<PRE>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">  struct V {
    virtual void f();
  };

  struct A : virtual V { };

  struct B : virtual V {
    B(V*, A*);
  };

  struct D : A, B {
    D() : B((A*)this, this) { }
  };

  B::B(V* v, A* a) {
    typeid(*this);       //<SPAN style="font-family:Times;font-style:italic"> </SPAN>type_info<SPAN style="font-family:Times;font-style:italic"> for </SPAN>B
    typeid(*v);          //<SPAN style="font-family:Times;font-style:italic"> well-defined: </SPAN>*v<SPAN style="font-family:Times;font-style:italic"> has type </SPAN>V<SPAN style="font-family:Times;font-style:italic">, a base of </SPAN>B
                         //<SPAN style="font-family:Times;font-style:italic"> yields </SPAN>type_info<SPAN style="font-family:Times;font-style:italic"> for </SPAN>B
    typeid(*a);          //<SPAN style="font-family:Times;font-style:italic"> undefined behavior: type </SPAN>A<SPAN style="font-family:Times;font-style:italic"> not a base of </SPAN>B
    dynamic_cast&lt;B*&gt;(v); //<SPAN style="font-family:Times;font-style:italic"> well-defined: </SPAN>v<SPAN style="font-family:Times;font-style:italic"> of type </SPAN>V*<SPAN style="font-family:Times;font-style:italic">, </SPAN>V<SPAN style="font-family:Times;font-style:italic"> base of </SPAN>B
                         //<SPAN style="font-family:Times;font-style:italic"> results in </SPAN>B*
    dynamic_cast&lt;B*&gt;(a); //<SPAN style="font-family:Times;font-style:italic"> undefined behavior,</SPAN>
                         //<SPAN style="font-family:Times;font-style:italic"> </SPAN>a<SPAN style="font-family:Times;font-style:italic"> has type </SPAN>A*<SPAN style="font-family:Times;font-style:italic">, </SPAN>A<SPAN style="font-family:Times;font-style:italic"> not a base of </SPAN>B</SPAN>
</PRE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">&#8212;<I>end example</I>]</SPAN></P>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1590"></A><H4>1590.
  
Bypassing non-copy/move constructor copying
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2012-11-26<BR>




<P>Copy initialization in some cases uses constructors that are not
copy/move constructors (e.g., a specialization of a constructor
template might be selected by overload resolution, or in
copy-list-initialization, any constructor could be selected).  Some
ABIs require that an object of certain class types be passed in a
register (effectively using the trivial copy/move constructor), even
if the class has a non-trivial constructor that would be selected to
do the copy.  The Standard should be changed to permit this usage.</P>

<P><B>Proposed resolution (April, 2013):</B></P>

<P>Add the following as a new paragraph following 12.8 [class.copy]
paragraph 1:</P>

<BLOCKQUOTE>

When an object of class type <TT>X</TT> is passed to or returned from a
function, if <TT>X</TT> has a trivial, accessible copy or move constructor that
is not deleted, and <TT>X</TT> has no non-trivial copy constructors, move
constructors, or destructors, implementations are permitted to perform
an additional copy or move of the object using the trivial constructor
(even if it would not be selected by overload resolution to perform a
copy or move of the object).  [<I>Note:</I> This latitude is granted to allow
objects of class type to be passed to or returned from functions in
registers &#8212;<I>end note</I>]

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1673"></A><H4>1673.
  
Clarifying overload resolution for the second step of copy-initialization
</H4><B>Section: </B>13.3.3.1&#160; [over.best.ics]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Vinny Romano
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-29<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA5">N3690 comment
  CA&#160;5<BR></A>



<P>Currently, 13.3.3.1 [over.best.ics] paragraph 4 reads,</P>

<BLOCKQUOTE>

However, when considering the argument of a constructor or user-defined
conversion function that is a candidate by 13.3.1.3 [over.match.ctor]
when invoked for the copying/moving of the temporary in the second step of
a class copy-initialization, by 13.3.1.7 [over.match.list] when passing
the initializer list as a single argument or when the initializer list has
exactly one element and a conversion to some class <TT>X</TT> or reference
to (possibly cv-qualified) <TT>X</TT> is considered for the first parameter
of a constructor of <TT>X</TT>, or by 13.3.1.4 [over.match.copy],
13.3.1.5 [over.match.conv], or 13.3.1.6 [over.match.ref] in all
cases, only standard conversion sequences and ellipsis conversion sequences
are considered.

</BLOCKQUOTE>

<P>This is cumbersome and hard to understand.  A possible improvement
might be:</P>

<BLOCKQUOTE>

<P>However, only standard conversion sequences and ellipsis conversion
sequences are considered if:</P>

<UL><LI><P>the parameter is the first parameter of a constructor of a
class <TT>X</TT>, or</P></LI>

<LI><P>the parameter is the implicit object parameter of a user-defined
conversion function, and</P></LI>

<LI><P>the constructor or user-defined conversion function is a candidate
by:</P></LI>



<P STYLE="margin-left:.35in;text-indent:-.35in">13.3.1.3 [over.match.ctor]
&#8212; when the argument is the temporary being copied/moved in the second
step of a class copy-initialization.</P>

<P STYLE="margin-left:.35in;text-indent:-.35in">13.3.1.4 [over.match.copy],
13.3.1.5 [over.match.conv], or 13.3.1.6 [over.match.ref] &#8212; in
all cases.</P>

<P STYLE="margin-left:.35in;text-indent:-.35in">13.3.1.7 [over.match.list]
&#8212; during phase two, when the argument was the only element in the
initializer list, and the parameter is of type <TT>X</TT> or reference to
(possibly cv-qualified) <TT>X</TT>.</P>

</UL>

</BLOCKQUOTE>

<P>(Note that this rewording removes the restriction that applies
during phase one of 13.3.1.7 [over.match.list], as there is no
longer any way to trigger it due to the fact that only
initializer-list constructors are candidates.  See
<A HREF="http://llvm.org/bugs/show_bug.cgi?id=12117">this bug report</A>
for details.)</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change 13.3.3.1 [over.best.ics] paragraph 4 as follows:</P>

<BLOCKQUOTE>

<P>However, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">when considering the argument of a constructor or
user-defined conversion function that is a candidate by
13.3.1.3 [over.match.ctor] when invoked for the copying/moving of the
temporary in the second step of a class copy-initialization, by
13.3.1.7 [over.match.list] when passing the initializer list as a single
argument or when the initializer list has exactly one element and a
conversion to some class <TT>X</TT> or reference to (possibly
cv-qualified) <TT>X</TT> is considered for the first parameter of a
constructor of <TT>X</TT>, or by 13.3.1.4 [over.match.copy],
13.3.1.5 [over.match.conv], or 13.3.1.6 [over.match.ref] in all
cases, only standard conversion sequences and ellipsis conversion sequences
are considered.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">if the target is</SPAN></P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">the first parameter of a constructor of a class <TT>X</TT>
or</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">the implicit object parameter of a user-defined conversion
function,</SPAN></P></LI>

</UL>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">and the constructor or user-defined conversion function is a
candidate by</SPAN></P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">13.3.1.3 [over.match.ctor], when the argument is the
temporary acting as the source in the second step of a class
copy-initialization,</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">13.3.1.4 [over.match.copy],
13.3.1.5 [over.match.conv], or
13.3.1.6 [over.match.ref] (in all cases), or</SPAN></P></LI>

<LI>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">the second phase of 13.3.1.7 [over.match.list] when the
initializer list has exactly one element, and the conversion is
to <TT>X</TT> or reference to (possibly
cv-qualified) <TT>X</TT>,</SPAN></P></LI>

</UL>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">user-defined conversion sequences are not
considered. [<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  struct X { X(); };
  struct B { operator X&amp;(); };
  B b;
  X x({b}); //<SPAN style="font-family:Times;font-style:italic"> error: </SPAN>B::operator X&amp;()<SPAN style="font-family:Times;font-style:italic"> is not a candidate</SPAN></SPAN>
</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end example</I>]</SPAN></P>

</BLOCKQUOTE>

<P><B>Additional note (October, 2013):</B></P>

<P>Questions have been raised about several of the bullets in the
September, 2013 proposed resolution and whether a note would be
preferable instead of or in addition to the example  .  The issue
has been returned to "review" status to allow consideration of these
questions.</P>

<BR><BR><HR><A NAME="1484"></A><H4>1484.
  
Unused local classes of function templates
</H4><B>Section: </B>14.7.1&#160; [temp.inst]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2012-03-25<BR>




<P>Do local classes of function templates get the same treatment as
member classes of class templates? In particular, is their definition
only instantiated when they are required? For example,</P>

<PRE>
  template&lt;typename T&gt; void f() {
    struct B {
      T t;
    };
  }

  int main() {
    f&lt;void&gt;();
  }
</PRE>

<P>Implementations vary on this question.</P>

<P>(This question is superficially similar to the one in
<A HREF="
     cwg_active.html#1253">issue 1253</A>. However, the entities in
view in that issue can be named and defined outside the containing
template and thus can be explicitly specialized, none of which is
true for local classes of function templates.)</P>

<P>It should also be noted that the resolution of this issue should
apply as well to local enumeration types.</P>

<P><B>Proposed resolution (October, 2012):</B></P>

<P>Change 14.7.1 [temp.inst] paragraph 1 as follows:</P>

<BLOCKQUOTE>

Unless a class template specialization has been explicitly
instantiated (14.7.2 [temp.explicit]) or explicitly specialized
(14.7.3 [temp.expl.spec]), the class template specialization is
implicitly instantiated when the specialization is referenced in a
context that requires a completely-defined object type or when the
completeness of the class type affects the semantics of the program.
<SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I> Within a template declaration, a local class or
enumeration and the members of a local class are never considered to
be entities that can be separately instantiated (this includes their
default arguments, <I>exception-specification</I>s, and non-static data
member initializers, if any). As a result, the dependent names are
looked up, the semantic constraints are checked, and any templates
used are instantiated as part of the instantiation of the entity
within which the local class or enumeration is declared. &#8212;<I>end
note</I>]</SPAN> The implicit instantiation of a class template
specialization...

</BLOCKQUOTE>

<P><B>Notes from the April, 2013 meeting:</B></P>

<P>The proposed resolution interacts with N3649 (generic lambdas),
adopted at this meeting, and this issue has returned to "review"
status to allow any necessary changes to be made.</P>

<BR><BR><HR><A NAME="1584"></A><H4>1584.
  
Deducing function types from cv-qualified types
</H4><B>Section: </B>14.8.2.1&#160; [temp.deduct.call]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2012-11-04<BR>




<P>It is not clear whether the following is well-formed or not:</P>

<PRE>
  void foo(){}

  template&lt;class T&gt;
  void deduce(const T*) { }

  int main() {
    deduce(foo);
  }
</PRE>

<P>Implementations vary in their treatment of this example.</P>

<P><B>Proposed resolution (April, 2013):</B></P>

<P>Change 14.8.2.5 [temp.deduct.type] paragraph 18 as follows:</P>

<BLOCKQUOTE>

<P>A <I>template-argument</I> can be deduced from a function, pointer to
function, or pointer to member function type. <SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I>
cv-qualification of a deduced function type is ignored; see
8.3.5 [dcl.fct]. &#8212;<I>end note</I>]</SPAN>
[<I>Example:</I></P>

<PRE>
  template&lt;class T&gt; void f(void(*)(T,int));
<SPAN style="font-weight:bold;background-color:#A0FFA0">  template&lt;class T&gt; void f2(const T*);</SPAN>
  template&lt;class T&gt; void foo(T,int);
  void g(int,int);
  void g(char,int);
<SPAN style="font-weight:bold;background-color:#A0FFA0">  void g2();</SPAN>

  void h(int,int,int);
  void h(char,int);
  int m() {
    f(&amp;g);     //<SPAN style="font-family:Times;font-style:italic"> error: ambiguous</SPAN>
    f(&amp;h);     //<SPAN style="font-family:Times;font-style:italic"> OK: </SPAN>void h(char,int)<SPAN style="font-family:Times;font-style:italic"> is a unique match</SPAN>
    f(&amp;foo);   //<SPAN style="font-family:Times;font-style:italic"> error: type deduction fails because </SPAN>foo<SPAN style="font-family:Times;font-style:italic"> is a template</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">    f2(g2);    //<SPAN style="font-family:Times;font-style:italic"> OK: cv-qualification of deduced function type ignored</SPAN></SPAN>
  }
</PRE>

<P>&#8212;<I>end example</I>]</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1705"></A><H4>1705.
  
Unclear specification of &#8220;more specialized&#8221;
</H4><B>Section: </B>14.8.2.4&#160; [temp.deduct.partial]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2013-06-26<BR>




<P>The current wording of 14.8.2.4 [temp.deduct.partial] paragraph 10
is:</P>

<BLOCKQUOTE>

If for each type being considered a given template is at least as
specialized for all types and more specialized for some set of types and
the other template is not more specialized for any types or is not at least
as specialized for any types, then the given template is more specialized
than the other template. Otherwise, neither template is more specialized
than the other.

</BLOCKQUOTE>

<P>This is confusing and needs to be clarified.</P>



<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change 14.8.2.4 [temp.deduct.partial] paragraphs 9 and 10 as follows:</P>

<BLOCKQUOTE>

<P>If, for a given type, deduction succeeds in both directions (i.e., the
types are identical after the transformations above) and both <TT>P</TT>
and <TT>A</TT> were reference types (before being replaced with the type
referred to above):</P>

<UL><LI><P>if the type from the argument template was an lvalue reference
and the type from the parameter template was not, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the argument type is
considered to be more specialized than the other</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">the other type
is not considered to be at least as specialized as the argument type</SPAN>;
otherwise,</P></LI>

<LI><P>if the type from the argument template is more cv-qualified than the
type from the parameter template (as described above), <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the argument
type is considered to be more specialized than the other; otherwise,</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">the other type is not considered to be at least as specialized as the
argument type.</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">neither type is more specialized than the other.</SPAN></P></LI>

</UL>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">If for each type being considered a given template is at least as
specialized for all types and more specialized for some set of types and
the other template is not more specialized for any types or is not at least
as specialized for any types, then the given template is more specialized
than the other template. Otherwise, neither template is more specialized
than the other.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">A given template is at least as specialized as
another template if it is at least as specialized as the other template
for all types being considered.  A given template is more specialized than
another template if it is at least as specialized as the other template
for all types being considered, and the other template is not at least as
specialized as the given template for any type being considered.</SPAN></P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1769"></A><H4>1769.
  
Catching a base class of the exception object
</H4><B>Section: </B>15.3&#160; [except.handle]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Canada
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-24<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA13">N3690 comment
  CA&#160;13<BR></A>

<P>In saying that the catch-clause parameter is copy-initialized from
the exception object, 15.3 [except.handle] paragraph 16 leaves open
the possibility that a converting constructor might be used for the
initialization when the type of the <I>exception-declaration</I> is
a base of the type of the exception object.  It should be specified
that the parameter is copy-constructed from the corresponding base class
subobject in such cases.</P>

<P><B>Proposed resolution (September, 2013):</B></P>

<P>Change 15.3 [except.handle] paragraph 16 as follows:</P>

<BLOCKQUOTE>

<P>If
the <I>exception-declaration</I> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">specifies</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">introduces</SPAN>
a name, it declares a variable<SPAN style="text-decoration:line-through;background-color:#FFA0A0"> which is copy-initialized
(8.5 [dcl.init]) from the exception object. If
the <I>exception-declaration</I> denotes an object type but does not
specify a name, a temporary (12.2 [class.temporary]) is copy-initialized
(8.5 [dcl.init]) from the exception object.</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">;
otherwise, an unnamed variable is created.  That variable, of type
<I>cv</I> <TT>T</TT> or <I>cv</I> <TT>T&amp;</TT>, is initialized from
the exception object, of type <TT>E</TT>, as follows:</SPAN></P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if <TT>T</TT> is a base class of <TT>E</TT>, the variable
is copy-initialized from the corresponding base class subobject of the
exception object;</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">otherwise, the variable is copy-initialized from the
exception object.</SPAN></P></LI>

<P>The lifetime of the variable <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or temporary</SPAN> ends when the
handler exits, after the destruction of any automatic objects initialized
within the handler.</P>

</UL>

</BLOCKQUOTE>

<P><B>Additional note (October, 2013):</B></P>

<P>Additional discussion  has pointed out that, although the
unnamed handler parameter is no longer called a &#8220;temporary&#8221; in
the proposed resolution, 12.2 [class.temporary] paragraph 1 still lists
&#8220;entering a handler (15.3 [except.handle])&#8221; as one of the
contexts in which a temporary is created.  A question was also raised as to
whether it is necessary to deal with named and unnamed handler parameters
separately, since both are now referred to as &#8220;variables&#8221; in
the revised wording.  This issue has therefore been returned to "review"
status to allow consideration of these points.</P>

<BR><BR><HR><A NAME="1351"></A><H4>1351.
  
Problems with implicitly-declared <I>exception-specification</I>s
</H4><B>Section: </B>15.4&#160; [except.spec]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2011-08-16<BR>




<P>The determination of the <I>exception-specification</I> for an
implicitly-declared special member function, as described in
15.4 [except.spec] paragraph 14, does not take into account the
fact that nonstatic data member initializers and default arguments in
default constructors can contain <I>throw-expression</I>s, which are
not part of the <I>exception-specification</I> of any function that is
&#8220;directly invoked&#8221; by the implicit definition.  Also, the
reference to &#8220;directly invoked&#8221; functions is not
restricted to potentially-evaluated expressions, thus possibly
including irrelevant <I>exception-specification</I>s.</P>

<P><B>Additional note (August, 2012):</B></P>

<P>The direction established by CWG for resolving this issue was to
consider functions called from default arguments and non-static data
member initializers in determining the <I>exception-specification</I>.
This leads to a problem with ordering: because non-static data member
initializers can refer to members declared later, their effect cannot
be known until the end of the class.  However, a non-static data
member initializer could possibly refer to an implicitly-declared
constructor, either its own or that of an enclosing class.
</P>

<P><B>Proposed resolution (October, 2012) [SUPERSEDED]:</B></P>

<OL><LI><P>Add the following two new paragraphs and make the indicated
changes to 15.4 [except.spec] paragraph 14:</P></LI>

<BLOCKQUOTE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">A <I>set of potential exceptions</I> may contain types and the
special value &#8220;any.&#8221; The <I>set of potential exceptions of
an expression</I> is the union of all sets of potential exceptions of
each potentially-evaluated subexpression <TT>e</TT>:</SPAN></P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>e</TT> is a call to a function, member function,
function pointer, or member function pointer (including implicit
calls, such as a call to the allocation function in a
<I>new-expression</I>):</SPAN></P></LI>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if it has a non-throwing
<I>exception-specification</I> or the call is a core constant
expression (5.19 [expr.const]), the set is
empty;</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">otherwise, if it has a
<I>dynamic-exception-specification</I>, the set consists of every type in
that <I>dynamic-exception-specification</I>;</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">otherwise, the set consists of &#8220;any.&#8221;</SPAN></P></LI>

</UL>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>e</TT> is a <I>throw-expression</I> (15.1 [except.throw]), the set consists of the type of the exception object
that would be initialized by the operand if present, or
&#8220;any&#8221; otherwise.</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>e</TT> is a <TT>dynamic_cast</TT> expression that
casts to a reference type and requires a run-time check (5.2.7 [expr.dynamic.cast]), the set consists of the type
<TT>std::bad_cast</TT>.</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>e</TT> is a <TT>typeid</TT> expression applied to a
glvalue expression whose type is a polymorphic class type
(5.2.8 [expr.typeid]), the set consists of the type
<TT>std::bad_typeid</TT>.</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>e</TT> is a <I>new-expression</I> with a
non-constant <I>expression</I> in the <I>noptr-new-declarator</I>
(5.3.4 [expr.new]), the set also includes the type
<TT>std::bad_array_new_length</TT>.</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">Otherwise, the set is the empty set.</SPAN></P></LI>

</UL>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">The <I>set of potential exceptions of a function</I>
<TT>f</TT> of some class <TT>X</TT>, where <TT>f</TT> is an inheriting
constructor or an implicitly-declared special member function, is
defined as follows: </SPAN></P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>f</TT> is a constructor, the set is the union of the
sets of potential exceptions of the constructor invocations for
<TT>X</TT>'s non-variant non-static data members, for <TT>X</TT>'s
direct base classes, and, if <TT>X</TT> is non-abstract (10.4 [class.abstract]), for <TT>X</TT>'s virtual base classes, as selected by
overload resolution for the implicit definition of <TT>f</TT>
(12.1 [class.ctor]), including default argument expressions
used in such invocations. [<I>Note:</I> Even though destructors for fully
constructed subobjects are invoked when an exception is thrown during
the execution of a constructor (15.2 [except.ctor]), their
<I>exception-specification</I>s do not contribute to the
<I>exception-specification</I> of the constructor, because an
exception thrown from such a destructor could never escape the
constructor (15.1 [except.throw], 15.5.1 [except.terminate]). &#8212;<I>end note</I>]</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>f</TT> is a default constructor or inheriting
constructor, the set also contains all members of the sets of
potential exceptions of the initialization of non-static data members
from <I>brace-or-equal-initializer</I>s.</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>f</TT> is an assignment operator, the set is the
union of the sets of potential exceptions of the assignment operator
invocations for <TT>X</TT>'s non-variant non-static data members and
for <TT>X</TT>'s virtual and direct base classes, as selected by
overload resolution for the implicit definition of <TT>f</TT>
(12.8 [class.copy]), including default argument expressions
used in such invocations.</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>f</TT> is a destructor, the set is the union of the
sets of potential exceptions of the destructor invocations for
<TT>X</TT>'s non-variant non-static data members and for <TT>X</TT>'s
virtual and direct base classes.</SPAN></P></LI>

</UL>

<P>An inheriting constructor (12.9 [class.inhctor]) and an
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">implicitly declared</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">implicitly-declared</SPAN> special
member function (Clause 12 [special]) <SPAN style="text-decoration:line-through;background-color:#FFA0A0">have an</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">are considered to have an implicit</SPAN>
<I>exception-specification</I>.  <SPAN style="text-decoration:line-through;background-color:#FFA0A0">If <TT>f</TT> is an inheriting
constructor or an implicitly declared default constructor, copy
constructor, move constructor, destructor, copy assignment operator,
or move assignment operator, its implicit
<I>exception-specification</I> specifies the <I>type-id</I> <TT>T</TT>
if and only if <TT>T</TT> is allowed by the
<I>exception-specification</I> of a function directly invoked by
<TT>f</TT>'s implicit definition; <TT>f</TT> allows all exceptions if
any function it directly invokes allows all exceptions, and <TT>f</TT>
has the <I>exception-specification</I> <TT>noexcept(true)</TT> if
every function it directly invokes allows no exceptions.</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">The implicit <I>exception-specification</I> is
<TT>noexcept(false)</TT> if the set of potential exceptions of the
function contains &#8220;any;&#8221; otherwise, if that set
contains at least one type, the implicit exception-specification
specifies each type T contained in the set; otherwise, the implicit
<I>exception-specification</I> is <TT>noexcept(true)</TT>.</SPAN>
[<I>Note:</I> An instantiation of an inheriting constructor template
has an implied <I>exception-specification</I> as if it were a
non-template inheriting constructor. &#8212;<I>end note</I>]
[<I>Example:</I></P>

<PRE>
  struct A {
    A();
    A(const A&amp;) throw();
    A(A&amp;&amp;) throw();
    ~A() throw(X);
  };
  struct B {
    B() throw();
    B(const B&amp;) throw();
    B(B&amp;&amp;<SPAN style="font-weight:bold;background-color:#A0FFA0">, int = (throw Y(), 0)</SPAN>) throw(Y)<SPAN style="text-decoration:line-through;background-color:#FFA0A0"></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">noexcept</SPAN>;
    ~B() throw(Y);
  };
  struct D : public A, public B {
      //<SPAN style="font-family:Times;font-style:italic"> Implicit declaration of D::D();</SPAN>
      //<SPAN style="font-family:Times;font-style:italic"> Implicit declaration of D::D(const D&amp;) noexcept(true);</SPAN>
      //<SPAN style="font-family:Times;font-style:italic"> Implicit declaration of D::D(D&amp;&amp;) throw(Y);</SPAN>
      //<SPAN style="font-family:Times;font-style:italic"> Implicit declaration of D::~D() throw(X, Y);</SPAN>
  };
</PRE>

<P>Furthermore, if...</P>

</BLOCKQUOTE>

<LI><P>Change 5.3.7 [expr.unary.noexcept] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

<P>The result of the noexcept operator is <TT>false</TT> if <SPAN style="text-decoration:line-through;background-color:#FFA0A0">in a
potentially-evaluated context</SPAN> the <SPAN style="font-weight:bold;background-color:#A0FFA0">set of potential
exceptions of the</SPAN> expression <SPAN style="font-weight:bold;background-color:#A0FFA0">(15.4 [except.spec])</SPAN> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">would contain</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">contains
&#8220;any&#8221; or at least one type and <TT>true</TT>
otherwise.</SPAN></P>

<UL><LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">a potentially evaluated call<SUP>80</SUP> to a
function, member function, function pointer, or member function
pointer that does not have a non-throwing
<I>exception-specification</I> (15.4 [except.spec]), unless the
call is a constant expression (5.19 [expr.const]),</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">a potentially evaluated <I>throw-expression</I> (15.1 [except.throw]),</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">a potentially evaluated <TT>dynamic_cast</TT> expression
<TT>dynamic_cast&lt;T&gt;(v)</TT>, where <TT>T</TT> is a reference
type, that requires a run-time check (5.2.7 [expr.dynamic.cast]),
or</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">a potentially evaluated <TT>typeid</TT> expression (5.2.8 [expr.typeid]) applied to a glvalue expression whose type is a
polymorphic class type (10.3 [class.virtual]).</SPAN></P></LI>

</UL>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">Otherwise, the result is <TT>true</TT>.</SPAN></P>

</BLOCKQUOTE>

</OL>

<P>(This resolution also resolves issues
<A HREF="
     cwg_active.html#1356">1356</A> and <A HREF="
     cwg_active.html#1465">1465</A>.)</P>

<P><B>Additional note (October, 2012):</B></P>

<P>The preceding wording has been modified from the version that
was reviewed following the October, 2012 meeting and thus has been
returned to "review" status.</P>

<P><B>Additional note (March, 2013):</B></P>

<P>It has been suggested that it might be more consistent with
other parts of the language, and particularly in view of the
deprecation of <I>dynamic-exception-specification</I>s, if a
potentially-throwing non-static data member initializer simply made
an implicit constructor <TT>noexcept(false)</TT> instead of
giving it a set of potential exception types.</P>

<P><B>Additional note, April, 2013:</B></P>

<P>One problem with the approach suggested in the preceding note
would be something like the following example:</P>

<PRE>
  struct S {
    virtual ~S() throw(int);
  };
  struct D: S { };
</PRE>

<P>This approach would make the example ill-formed, because
the derived class destructor would be declared to throw
types not permitted by the base class
destructor's <I>exception-specification</I>.  A further
elaboration on the suggestion above that would not have this
objection would be to define all
<I>dynamic-exception-specification</I>s as simply equivalent to
<TT>noexcept(false)</TT>.</P>

<P>(See also <A HREF="
     cwg_active.html#1639">issue 1639</A>.)</P>

<P><B>Proposed resolution, April, 2013:</B></P>

<OL><LI><P>Change 8.4.2 [dcl.fct.def.default] paragraph 2 as
follows:</P></LI>

<BLOCKQUOTE>

An explicitly-defaulted function may be declared constexpr
only if it would have been implicitly declared as constexpr,
and may have an explicit <I>exception-specification</I> only
if it is compatible (15.4 [except.spec]) with
the <I>exception-specification</I> on the implicit
declaration <SPAN style="font-weight:bold;background-color:#A0FFA0">or if the function is defined as
deleted</SPAN>. If a function is explicitly defaulted...

</BLOCKQUOTE>

<LI><P>Change 15.4 [except.spec] paragraph 5 as follows:</P></LI>

<BLOCKQUOTE>

If a virtual function has an <I>exception-specification</I>,
all declarations, including the definition, of any function
that overrides that virtual function in any derived class
shall only allow exceptions that are allowed by
the <I>exception-specification</I> of the base class virtual
function<SPAN style="font-weight:bold;background-color:#A0FFA0">, unless the overriding function is defined as
deleted</SPAN>. [<I>Example:</I>...

</BLOCKQUOTE>

<LI><P>Add the following two new paragraphs and change
15.4 [except.spec] paragraph 14 as indicated:</P></LI>

<BLOCKQUOTE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">A <I>set of potential exceptions</I> may contain
types and the special value &#8220;any&#8221;. The <I>set of
potential exceptions of an expression</I> is the union of
all sets of potential exceptions of each
potentially-evaluated subexpression <TT>e</TT>:</SPAN></P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>e</TT> is a core constant expression
(5.19 [expr.const]), the set is
empty.</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">Otherwise, if <TT>e</TT> is a function call
(5.2.2 [expr.call]) whose <I>postfix-expression</I>
is not a (possibly parenthesized) <I>id-expression</I>
(5.1.1 [expr.prim.general]) or class member access
(5.2.5 [expr.ref]), the set consists of
&#8220;any&#8221;.</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">Otherwise, if <TT>e</TT> invokes a function,
member function, or function pointer (including implicit
calls, such as to an overloaded operator or to an allocation
function in a <I>new-expression</I>):</SPAN></P></LI>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if its declaration has a
non-throwing <I>exception-specification</I>, the set is
empty;</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">otherwise, if its declaration has
a <I>dynamic-exception-specification</I>, the set consists
of every type in
that <I>dynamic-exception-specification</I>;</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">otherwise, the set consists of
&#8220;any&#8221;.</SPAN></P></LI>

</UL>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>e</TT> is a <I>throw-expression</I>
(15.1 [except.throw]), the set consists of the type of
the exception object that would be initialized by the
operand if present, or &#8220;any&#8221; otherwise.</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>e</TT> is a <TT>dynamic_cast</TT> expression
that casts to a reference type and requires a run-time check
(5.2.7 [expr.dynamic.cast]), the set consists of the
type <TT>std::bad_cast</TT>.</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>e</TT> is a <TT>typeid</TT> expression applied
to a glvalue expression whose type is a polymorphic class
type (5.2.8 [expr.typeid]), the set consists of the
type <TT>std::bad_typeid</TT>.</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>e</TT> is a <I>new-expression</I> with a
non-constant expression in the <I>noptr-new-declarator</I>
(5.3.4 [expr.new]), the set also includes the
type <TT>std::bad_array_new_length</TT>.</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If none of the previous items applies, the set is the
empty set.</SPAN></P></LI>

</UL>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">The <I>set of potential exceptions of an
implicitly-declared special member function</I> <TT>f</TT>
of some class <TT>X</TT> is defined as follows:</SPAN></P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>f</TT> is a constructor, the set is the
union of the sets of potential exceptions of the constructor
invocations for <TT>X</TT>'s non-variant non-static data
members, for <TT>X</TT>'s direct base classes, and,
if <TT>X</TT> is non-abstract (10.4 [class.abstract]),
for <TT>X</TT>'s virtual base classes, as selected by
overload resolution for the implicit definition
of <TT>f</TT> (12.1 [class.ctor]), including default
argument expressions used in such invocations. [<I>Note:</I>
Even though destructors for fully constructed subobjects are
invoked when an exception is thrown during the execution of
a constructor (15.2 [except.ctor]),
their <I>exception-specification</I>s do not contribute to
the <I>exception-specification</I> of the constructor,
because an exception thrown from such a destructor could
never escape the constructor (15.1 [except.throw],
15.5.1 [except.terminate]). &#8212;<I>end
note</I>]</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>f</TT> is a default constructor, the set also
contains all members of the sets of potential exceptions of
the initialization of non-static data members
from <I>brace-or-equal-initializer</I>s.</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>f</TT> is an assignment operator, the set is
the union of the sets of potential exceptions of the
assignment operator invocations for <TT>X</TT>'s non-variant
non-static data members and for <TT>X</TT>'s virtual and
direct base classes, as selected by overload resolution for
the implicit definition of <TT>f</TT>
(12.8 [class.copy]), including default argument
expressions used in such invocations.</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>f</TT> is a destructor, the set is the union
of the sets of potential exceptions of the destructor
invocations for <TT>X</TT>'s non-variant non-static data
members and for <TT>X</TT>'s virtual and direct base
classes.</SPAN></P></LI>

</UL>

<P>An inheriting constructor (12.9 [class.inhctor]) and
an implicitly<SPAN style="font-weight:bold;background-color:#A0FFA0">-</SPAN>declared special member function
(Clause 12 [special]) <SPAN style="text-decoration:line-through;background-color:#FFA0A0">have</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">are
considered to have</SPAN>
an <SPAN style="font-weight:bold;background-color:#A0FFA0">implicit</SPAN> <I>exception-specification</I>. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">If <TT>f</TT>
is an inheriting constructor or an implicitly declared
default constructor, copy constructor, move constructor,
destructor, copy assignment operator, or move assignment
operator, its implicit <I>exception-specification</I>
specifies the <I>type-id</I> <TT>T</TT> if and only
if <TT>T</TT> is allowed by
the <I>exception-specification</I> of a function directly
invoked by <TT>f</TT>'s implicit definition; <TT>f</TT>
allows all exceptions if any function it directly invokes
allows all exceptions, and <TT>f</TT> has
the <I>exception-specification</I>
<TT>noexcept(true)</TT> if every function it directly
invokes allows no exceptions. [<I>Note:</I> It follows
that <TT>f</TT> has the <I>exception-specification</I>
<TT>noexcept(true)</TT> if it invokes no other
functions. &#8212;<I>end note</I>]</SPAN> [<I>Note:</I> An
instantiation of an inheriting constructor template has an
implied <I>exception-specification</I> as if it were a
non-template inheriting constructor. &#8212;<I>end note</I>]
<SPAN style="font-weight:bold;background-color:#A0FFA0">The implicit <I>exception-specification</I> is
<TT>noexcept(false)</TT> if the set of potential exceptions of the
special member function contains &#8220;any&#8221;; otherwise, if that
set contains at least one type, the
implicit <I>exception-specification</I> specifies each type
<TT>T</TT> contained in the set; otherwise, the
implicit <I>exception-specification</I>
is <TT>noexcept(true)</TT>.</SPAN> [<I>Example:</I></P>

<PRE>
  struct A {
    A();
    A(const A&amp;) throw();
    A(A&amp;&amp;) throw();
    ~A() throw(X);
  };
  struct B {
    B() throw();
    B(const B&amp;) <SPAN style="text-decoration:line-through;background-color:#FFA0A0">= default; //<SPAN style="font-family:Times;font-style:italic"> Declaration of </SPAN>B::B(const B&amp;) noexcept(true)</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">throw();</SPAN>
    B(B&amp;&amp;<SPAN style="font-weight:bold;background-color:#A0FFA0">, int = (throw Y(), 0)</SPAN>) <SPAN style="text-decoration:line-through;background-color:#FFA0A0">throw(Y)</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">noexcept</SPAN>;
    ~B() throw(Y);
  };
  struct D : public A, public B {
      //<SPAN style="font-family:Times;font-style:italic"> Implicit declaration of D::D();</SPAN>
      //<SPAN style="font-family:Times;font-style:italic"> Implicit declaration of D::D(const D&amp;) noexcept(true);</SPAN>
      //<SPAN style="font-family:Times;font-style:italic"> Implicit declaration of D::D(D&amp;&amp;) throw(Y);</SPAN>
      //<SPAN style="font-family:Times;font-style:italic"> Implicit declaration of D::~D() throw(X, Y);</SPAN>
  };
</PRE>

<P>Furthermore...</P>

</BLOCKQUOTE>

<LI><P>Change 5.3.7 [expr.unary.noexcept]paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

<P>The result of the <TT>noexcept</TT> operator
is <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>false</TT></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>true</TT></SPAN>
if <SPAN style="text-decoration:line-through;background-color:#FFA0A0">in a potentially-evaluated context</SPAN>
the <SPAN style="font-weight:bold;background-color:#A0FFA0">set of potential exceptions of
the</SPAN> <I>expression</I> <SPAN style="font-weight:bold;background-color:#A0FFA0">(15.4 [except.spec])</SPAN> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">would
contain</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is empty, and <TT>false</TT>
otherwise.</SPAN></P>

<UL><LI>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">a potentially-evaluated call [<I>[Footnote:</I> This
includes implicit calls such as the call to an allocation
function in a <I>new-expression</I>.  &#8212;<I>end
footnote</I>] to a function, member function, function
pointer, or member function pointer that does not have a
non-throwing <I>exception-specification</I>
(15.4 [except.spec]), unless the call is a constant
expression (5.19 [expr.const]),</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">a potentially-evaluated <I>throw-expression</I>
(15.1 [except.throw]),</SPAN></P></LI>

<LI>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">a potentially-evaluated <TT>dynamic_cast</TT> expression
<TT>dynamic_cast&lt;T&gt;(v)</TT>, where <TT>T</TT> is a
reference type, that requires a run-time check
(5.2.7 [expr.dynamic.cast]), or</SPAN></P></LI>

<LI>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">a potentially-evaluated <TT>typeid</TT> expression
(5.2.8 [expr.typeid]) applied to a glvalue expression
whose type is a polymorphic class type
(10.3 [class.virtual]).</SPAN></P></LI>

</UL>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">Otherwise, the result is <TT>true</TT>.</SPAN></P>

</BLOCKQUOTE>

<P>(This resolution also resolves issues <A HREF="
     cwg_active.html#1356">1356</A>,
<A HREF="
     cwg_active.html#1465">1465</A>, and <A HREF="
     cwg_active.html#1639">1639</A>.)</P>

<P><B>Additional note, April, 2013:</B></P>

<P>The version of this resolution approved in Bristol
assumed the underlying text of the C++11 IS; however, the
wording of 15.4 [except.spec] paragraph 14 has been
changed by previous resolutions, so this and the related
issues are being returned to "review" status.</P>

</OL>

<BR><BR><HR><A NAME="1356"></A><H4>1356.
  
Exception specifications of copy assignment operators with virtual bases
</H4><B>Section: </B>15.4&#160; [except.spec]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Sean Hunt
 &#160;&#160;&#160;

 <B>Date: </B>2011-08-16<BR>




<P>It is unspecified if an implicitly-defined copy assignment operator
directly invokes the copy assignment operators of virtual bases.  The
<I>exception-specification</I> of such a copy assignment operator is
thus also unspecified.  The specification in 15.4 [except.spec]
paragraph 14 should explicitly include the exceptions from the copy
assignment operators of virtual base classes, regardless of whether the
implicit definition actually invokes the virtual base assignment operators
or not.</P>

<P><B>Proposed resolution (October, 2012):</B></P>

<P>This issue is resolved by the resolution of
<A HREF="
     cwg_active.html#1351">issue 1351</A>.</P>

<BR><BR><HR><A NAME="1639"></A><H4>1639.
  
<I>exception-specification</I>s and pointer/pointer-to-member expressions
</H4><B>Section: </B>15.4&#160; [except.spec]
 &#160;&#160;&#160;

 <B>Status: </B>review
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>2013-02-12<BR>


<P>The current specification is not clear whether the
<I>exception-specification</I> for a function is propagated to the
result of taking its address.  For example:</P>

<PRE>
  template&lt;class T&gt; struct A {
    void f() noexcept(false) {}
    void g() noexcept(true) {}
  };

  int main() {
    if (noexcept((A&lt;short&gt;().*(&amp;A&lt;short&gt;::f))()))
      return 1;

    if (!noexcept((A&lt;long&gt;().*(&amp;A&lt;long&gt;::g))()))
      return 1;

     return 0;
  } 
</PRE>

<P>There is implementation variance on whether <TT>main</TT> returns
0 or 1 for this example.  (It also appears that taking the address of
a member function of a class template requires instantiating its
<I>exception-specification</I>, but it is not clear whether the
Standard currently specifies this or not.)</P>

<P>(See also issues <A HREF="
     cwg_closed.html#92">92</A> and
<A HREF="
     cwg_active.html#1351">1351</A>.)</P>

<P><B>Proposed resolution (April, 2013):</B></P>

<P>This issue is resolved by the proposed resolution of
<A HREF="
     cwg_active.html#1351">issue 1351</A>.</P>

<BR><BR><BR><BR><HR><A NAME="Drafting Status"></A><H3>Issues with "Drafting" Status</H3>
<HR><A NAME="1343"></A><H4>1343.
  
Sequencing of non-class initialization
</H4><B>Section: </B>1.9&#160; [intro.execution]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2011-08-12<BR>




<P>The current wording does not indicate that initialization of a
non-class object is a full-expression, but presumably should do
so.</P>

<P><B>Additional note, April, 2013:</B></P>

<P>There is implementation variance in the treatment of the
following example:</P>

<PRE>
  struct A {
    A() { puts("ctor"); }
    A(const A&amp;) { puts("copy"); }
    const A&amp;get() const { return *this; }
    ~A() { puts("dtor"); }
  };
  struct B { B(A, A) {} };

  typedef A A2[2];
  A2 a = { A().get(), A().get() };
  B b = { A().get(), A().get() };
  int c = (A2{ A().get(), A().get() }, 0);
  int d = (B{ A().get(), A().get() }, 0);

  int main() {}
</PRE>



<BR><BR><HR><A NAME="1332"></A><H4>1332.
  
Handling of invalid universal-character-names
</H4><B>Section: </B>2.3&#160; [lex.charset]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2011-06-20<BR>


<P>According to 2.3 [lex.charset] paragraph 2,</P>

<BLOCKQUOTE>

The character designated by the universal-character-name
<TT>\UNNNNNNNN</TT> is that character whose character short name in
ISO/IEC 10646 is <TT>NNNNNNNN</TT>; the character designated by the
universal-character-name <TT>\uNNNN</TT> is that character whose
character short name in ISO/IEC 10646 is <TT>0000NNNN</TT>. If the
hexadecimal value for a universal-character-name corresponds to a
surrogate code point (in the range 0xD800-0xDFFF,
inclusive), the program is ill-formed. Additionally, if the
hexadecimal value for a universal-character-name outside the
<I>c-char-sequence</I>, <I>s-char-sequence</I>, or
<I>r-char-sequence</I> of a character or string literal corresponds to
a control character (in either of the ranges 0x00-0x1F or 0x7F-0x9F,
both inclusive) or to a character in the basic source character set,
the program is ill-formed.

</BLOCKQUOTE>

<P>It is not specified what should happen if the hexadecimal value
does not designate a Unicode code point: is that undefined behavior
or does it make the program ill-formed?</P>

<P>As an aside, a note should be added explaining why these
requirements apply to to an <I>r-char-sequence</I> when, as the
footnote at the end of the paragraph explains,</P>

<BLOCKQUOTE>

A sequence of characters resembling a universal-character-name in an
<I>r-char-sequence</I> (2.14.5 [lex.string]) does not form a
universal-character-name.

</BLOCKQUOTE>

<BR><BR><HR><A NAME="369"></A><H4>369.
  
Are <TT>new</TT>/<TT>delete</TT> identifiers or <I>preprocessing-op-or-punc</I>?
</H4><B>Section: </B>2.5&#160; [lex.pptoken]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Martin v. Loewis
 &#160;&#160;&#160;

 <B>Date: </B>30 July 2002<BR>


<P>2.5 [lex.pptoken] paragraph 2 specifies that there are 5
categories of tokens in phases 3 to 6. With 2.13 [lex.operators]
paragraph 1, it is unclear whether <TT>new</TT> is an <I>identifier</I> or a
<I>preprocessing-op-or-punc</I>; likewise for <TT>delete</TT>. This is
relevant to answer the question whether</P>
<PRE>
#define delete foo
</PRE>
<P>is a well-formed control-line, since that requires an identifier 
after the <TT>define</TT> token.</P>

<P>(See also <A HREF="
     cwg_active.html#189">issue 189</A>.)</P>

<BR><BR><HR><A NAME="1655"></A><H4>1655.
  
Line endings in raw string literals
</H4><B>Section: </B>2.5&#160; [lex.pptoken]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-26<BR>


<P>According to 2.5 [lex.pptoken] paragraph 3,</P>

<BLOCKQUOTE>

<P>If the input stream has been parsed into preprocessing
tokens up to a given character:</P>

<UL><LI>

<P>If the next character begins a sequence of characters that
could be the prefix and initial double quote of a raw string
literal, such as <TT>R"</TT>, the next preprocessing token shall be a
raw string literal. Between the initial and final double
quote characters of the raw string, any transformations
performed in phases 1 and 2 (trigraphs,
universal-character-names, and line splicing) are reverted;
this reversion shall apply before
any <I>d-char</I>, <I>r-char</I>, or delimiting parenthesis
is identified.</P></LI>

</UL>

</BLOCKQUOTE>

<P>However, phase 1 is defined as:</P>

<BLOCKQUOTE>

Physical source file characters are mapped, in an
implementation-defined manner, to the basic source character
set (introducing new-line characters for end-of-line
indicators) if necessary. The set of physical source file
characters accepted is implementation-defined. Trigraph
sequences (2.4 [lex.trigraph]) are replaced by
corresponding single-character internal representations. Any
source file character not in the basic source character set
(2.3 [lex.charset]) is replaced by the
universal-character-name that designates that character.

</BLOCKQUOTE>

<P>The reversion described in 2.5 [lex.pptoken] paragraph
3 specifically does not mention the replacement of physical
end-of-line indicators with new-line characters.  Is it intended
that, for example, a CRLF in the source of a raw string literal
is to be represented as a newline character or as the original
characters?</P>

<BR><BR><HR><A NAME="189"></A><H4>189.
  
Definition of <I>operator</I> and <I>punctuator</I>
</H4><B>Section: </B>2.13&#160; [lex.operators]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>20 Dec 1999<BR>





<P>The nonterminals <I>operator</I> and <I>punctuator</I> in
2.7 [lex.token]
 are not defined.  There is
a definition of the nonterminal <I>operator</I> in
13.5 [over.oper]
 paragraph 1, but it is
apparent that the two nonterminals are not the same: the latter
includes keywords and multi-token operators and does not include the
nonoverloadable operators mentioned in paragraph 3.</P>

<P>There is a definition of <I>preprocessing-op-or-punc</I> in
2.13 [lex.operators]
, with the notation that</P>

<BLOCKQUOTE>
Each <I>preprocessing-op-or-punc</I> is converted to a single token in
translation phase 7 (2.1).
</BLOCKQUOTE>

However, this list doesn't distinguish between <I>operator</I>s and
<I>punctuator</I>s, it includes digraphs and keywords (can a given
<I>token</I> be both a <I>keyword</I> and an <I>operator</I> at the
same time?), etc.

<P><B>Suggested resolution:</B></P>

<BR><OL>
<LI>Change 13.5 [over.oper]
 to use the term
<I>overloadable-operator</I>.</LI>

<LI>Change 2.7 [lex.token]
 to use the term
<I>operator-token</I> instead of <I>operator</I> (since there are
operators that are keywords and operators that are composed of more
than one token).</LI>

<LI>Change 2.13 [lex.operators]
 to define
the nonterminals <I>operator-token</I> and <I>punctuator</I>.</LI>
</OL>

<P><B>Additional note (April, 2005):</B></P>

<P>The resolution for this problem should also address the fact that
<TT>sizeof</TT> and <TT>typeid</TT> (and potentially others like
<TT>decltype</TT> that may be added in the future) are described in
some places as &#8220;operators&#8221; but are not listed in
13.5 [over.oper] paragraph 3 among the operators that cannot be
overloaded.</P>

<P>(See also <A HREF="
     cwg_active.html#369">issue 369</A>.)</P>
<BR><BR><HR><A NAME="1656"></A><H4>1656.
  
Encoding of numerically-escaped characters
</H4><B>Section: </B>2.14.3&#160; [lex.ccon]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-30<BR>


<P>According to 2.14.3 [lex.ccon] paragraph 4,</P>

<BLOCKQUOTE>

The escape <TT>\ooo</TT> consists of the backslash followed by one, two, or
three octal digits that are taken to specify the value of the desired
character. The escape <TT>\xhhh</TT> consists of the backslash followed
by <TT>x</TT> followed by one or more hexadecimal digits that are taken to
specify the value of the desired character. There is no limit to the number
of digits in a hexadecimal sequence. A sequence of octal or hexadecimal
digits is terminated by the first character that is not an octal digit or a
hexadecimal digit, respectively. The value of a character literal is
implementation-defined if it falls outside of the implementation-defined
range defined for <TT>char</TT> (for literals with no
prefix), <TT>char16_t</TT> (for literals prefixed
by <TT>'u'</TT>), <TT>char32_t</TT> (for literals prefixed
by <TT>'U'</TT>), or <TT>wchar_t</TT> (for literals prefixed
by <TT>'L'</TT>).

</BLOCKQUOTE>

<P>It is not clearly stated whether the &#8220;desired character&#8221;
being specified reflects the source or the target encoding.  This
particularly affects UTF-8 string literals (2.14.5 [lex.string]
paragraph 7):</P>

<BLOCKQUOTE>

A string literal that begins with <TT>u8</TT>, such as <TT>u8"asdf"</TT>,
is a UTF-8 string literal and is initialized with the given characters as
encoded in UTF-8.

</BLOCKQUOTE>

<P>For example, assuming the source encoding is Latin-1, is
<TT>u8"\xff"</TT> supposed to specify a three-byte string whose
first two bytes are <TT>0xc3 0xbf</TT> (the UTF-8 encoding of
<TT>\u00ff</TT>) or a two-byte string whose first byte has the
value <TT>0xff</TT>?  (At least some current implementations assume the
latter interpretation.)</P>

<P><B>Notes from the September, 2013 meeting:</B></P>

<P>The second interpretation (that the escape sequence specifies the
execution-time code unit) is intended.</P>

<BR><BR><HR><A NAME="1759"></A><H4>1759.
  
UTF-8 code units in plain <TT>char</TT>
</H4><B>Section: </B>2.14.5&#160; [lex.string]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>United Kingdom
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-23<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#GB1">N3690 comment
  GB&#160;1<BR></A>

<P>A UTF-8 string literal might result in a code unit with the value
<TT>0x80</TT>.  However, plain <TT>char</TT> is not guaranteed to be able to
represent <TT>0x80</TT>.</P>

<BR><BR><HR><A NAME="1723"></A><H4>1723.
  
Multicharacter user-defined character literals
</H4><B>Section: </B>2.14.8&#160; [lex.ext]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2013-07-31<BR>




<P>According to 2.14.3 [lex.ccon] paragraph 1, a multicharacter
literal like <TT>'ab'</TT> is conditionally-supported and has
type <TT>int</TT>.</P>

<P>According to 2.14.8 [lex.ext] paragraph 6,</P>

<BLOCKQUOTE>

<P>If <I>L</I> is a <I>user-defined-character-literal</I>, let <I>ch</I> be
the literal without its <I>ud-suffix</I>. <I>S</I> shall contain a literal
operator (13.5.8 [over.literal]) whose only parameter has the type
of <I>ch</I> and the literal <I>L</I> is treated as a call of the form</P>

<UL><TT>operator ""</TT> <I>X</I><TT>(</TT><I>ch</I><TT>)</TT></UL>

</BLOCKQUOTE>

<P>A <I>user-defined-character-literal</I> like <TT>'ab'_foo</TT> would
thus require a literal operator</P>

<UL><TT>operator "" _foo(int)</TT></UL>

<P>However, that is not one of the signatures permitted by
13.5.8 [over.literal] paragraph 3.</P>

<P>Should multicharacter <I>user-defined-character-literal</I>s be
conditionally-supported?  If so, 13.5.8 [over.literal] paragraph 3
should be adjusted accordingly.  If not, a note in
2.14.8 [lex.ext] paragraph 6 saying explicitly that they are not
supported would be helpful.</P>

<BR><BR><HR><A NAME="1735"></A><H4>1735.
  
Out-of-range literals in <I>user-defined-literal</I>s
</H4><B>Section: </B>2.14.8&#160; [lex.ext]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2013-08-12<BR>


<P>The description of the numeric literals occurring as part of
<I>user-defined-integer-literal</I>s and
<I>user-defined-floating-literal</I>s in 2.14.8 [lex.ext] says
nothing about whether they are required to satisfy the same constraints as
literals that are not part of a <I>user-defined-literal</I>.  In
particular, because it is the spelling, not the value, of the literal
that is used for raw literal operators and literal operator templates,
there is no particular reason that they should be restricted to the
maximum values and precisions that apply to ordinary literals (and one
could imagine that this would be a good notation for allowing literals
of extended-precision types).</P>

<P>Is this relaxation of limits intended to be required, or is it a
quality-of-implementation issue?  Should something be said, either
normatively or non-normatively, about this question?</P>

<BR><BR><HR><A NAME="1529"></A><H4>1529.
  
Nomenclature for variable vs reference non-static data member
</H4><B>Section: </B>3&#160; [basic]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2012-07-24<BR>




<P>According to 3 [basic] paragraph 6,</P>

<BLOCKQUOTE>

A <I>variable</I> is introduced by the declaration of a reference other than
a non-static data member or of an object.

</BLOCKQUOTE>

<P>In other words, non-static data members of reference type are not
variables.  This complicates the wording in a number of places, where
the text refers to &#8220;variable or data member,&#8221; presumably to
cover the reference case, but that phrasing could lead to the mistaken
impression that all data members are not variables.  It would be better
if either there were a term for the current phrase &#8220;variable or
data member&#8221; or if there were a less-unwieldy term for
&#8220;non-static data member of reference type&#8221; that could be
used in place of &#8220;data member&#8221; in the current phrasing.</P>

<BR><BR><HR><A NAME="1581"></A><H4>1581.
  
When are <TT>constexpr</TT> member functions defined?
</H4><B>Section: </B>3.2&#160; [basic.def.odr]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2012-10-29<BR>




<P>Clause 12 [special] is perfectly clear that special
member functions are only implicitly defined when they are
odr-used. This creates a problem for constant expressions in
unevaluated contexts:</P>

<PRE>
   struct duration {
     constexpr duration() {}
     constexpr operator int() const { return 0; }
   };
   // duration d = duration(); //<SPAN style="font-family:Times;font-style:italic"> #1</SPAN>
   int n = sizeof(short{duration(duration())});
</PRE>

<P>The issue here is that we are not permitted to implicitly define
<TT>constexpr duration::duration(duration&amp;&amp;)</TT> in this
program, so the expression in the initializer list is not a constant
expression (because it invokes a <TT>constexpr</TT> function which has
not been defined), so the braced initializer contains a narrowing
conversion, so the program is ill-formed.</P>

<P>If we uncomment line #1, the move constructor is implicitly defined
and the program is valid. This spooky action at a distance is
extremely unfortunate. Implementations diverge on this point.</P>

<P>There are also similar problems with implicit instantiation of
<TT>constexpr</TT> functions.  It is not clear which contexts require
their instantiation.  For example:</P>

<PRE>
  template&lt;int N&gt; struct U {};
  int g(int);
  template&lt;typename T&gt; constexpr int h(T) { return T::error; }
  template&lt;typename T&gt; auto f(T t) -&gt; U&lt;g(T()) + h(T())&gt; {}
  int f(...);
  int k = f(0);
</PRE>

<P>There are at least two different ways of modeling the current rules:</P>

<UL><LI><P><TT>constexpr</TT> function instantiation is triggered by
constant expression evaluation. In that case, the validity of the
above program depends on the order in which that evaluation
proceeds:</P></LI>

<UL><LI><P>If the LHS of the <TT>+</TT> is evaluated first, the program might
be valid, because the implementation might bail out evaluation before
triggering the ill-formed instantiation of <TT>h&lt;int&gt;</TT>.</P></LI>

<LI><P>If the RHS is evaluated first, the program is invalid, because
the instantiation fails.</P></LI>

</UL>

<LI><P><TT>constexpr</TT> function instantiation is triggered whenever
a <TT>constexpr</TT> function is referenced from an expression which
could be evaluated (note that this is not the same as being
potentially-evaluated)</P></LI>

</UL>

<P>These two approaches can be distinguished by code like this:</P>

<PRE>
  int k = sizeof(U&lt;0 &amp;&amp; h(0)&gt;);
</PRE>

<P>Under the first approach, this code is valid; under the second, it
is ill-formed.</P>

<P>A possible approach to resolving this issue would be to change the
definition of &#8220;potentially-evaluated&#8221; such that template
arguments, array bounds, and braced-init-lists (and any other
expressions which are constant evaluated) are always
potentially-evaluated, even if they appear within an unevaluated
context, and to change 14.7.1 [temp.inst] paragraph 3 to say
simply that function template specializations are implicitly
instantiated when they are odr-used.</P>

<P>A related question is whether putatively <TT>constexpr</TT>
constructors must be instantiated in order to determine whether their
class is a literal type or not.  See
<A HREF="
     cwg_defects.html#1358">issue 1358</A>.</P>

<P><U>Jason Merrill:</U></P>

<P>I'm concerned about unintended side-effects of such a large change
to &#8220;potentially-evaluated;&#8221; I would prefer something that
only affects <TT>constexpr</TT>.</P>

<P>It occurs to me that this is parallel to <A HREF="
     cwg_defects.html#1330">issue 1330</A>: just like we want to instantiate exception specifiers
for calls in unevaluated context, we also want to instantiate
<TT>constexpr</TT> functions.  I think we should define some other
term to say when there's a reference to a declaration, and then say
that the declaration is odr-used when that happens in
potentially-evaluated context.</P>

<P><B>Notes from the April, 2013 meeting:</B></P>

<P>An additional question was raised about whether <TT>constexpr</TT>
functions should be instantiated as a result of appearing within
unevaluated subexpressions of constant expressions. For example:</P>

<PRE>
  #include &lt;type_traits&gt;

  template &lt;class T&gt; constexpr T f(T t) { return +t; }

  struct A { };

  template &lt;class T&gt;
  decltype(std::is_scalar&lt;T&gt;::value ? T::fail : f(T()))
    g() { }

  template &lt;class T&gt;
  void g(...);

  int main()
  {
    g&lt;A&gt;();
  }

</PRE>

<P>If <TT>constexpr</TT> instantiation happens during constant expression
evaluation, <TT>f&lt;A&gt;</TT> is never instantiated and the program is
well-formed.  If <TT>constexpr</TT> instantiation happens during parsing,
<TT>f&lt;A&gt;</TT> is instantiated and the program is ill-formed.</P>

<BR><BR><HR><A NAME="554"></A><H4>554.
  
Definition of &#8220;declarative region&#8221; and &#8220;scope&#8221;
</H4><B>Section: </B>3.3&#160; [basic.scope]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Gabriel Dos Reis
 &#160;&#160;&#160;

 <B>Date: </B>29 December 2005<BR>




<P>The various uses of the term &#8220;declarative region&#8221;
throughout the Standard indicate that the term is intended to refer
to the entire block, class, or namespace that contains a given
declaration.  For example, 3.3 [basic.scope] paragraph 2
says, in part:</P>

<BLOCKQUOTE>

<P>[<I>Example:</I> in</P>

<PRE>
    int j = 24;
    int main()
    {
        int i = j, j;
        j = 42;
    }
</PRE>

<P>The declarative region of the first <TT>j</TT> includes the entire
example... The declarative region of the second declaration
of <TT>j</TT> (the <TT>j</TT> immediately before the semicolon)
includes all the text between <TT>{</TT> and <TT>}</TT>...</P>

</BLOCKQUOTE>

<P>However, the actual definition given for &#8220;declarative
region&#8221; in 3.3 [basic.scope] paragraph 1
does not match this usage:</P>

<BLOCKQUOTE>

Every name is introduced in some portion of program text called a
<I>declarative region</I>, which is the largest part of the program in
which that name is <I>valid</I>, that is, in which that name may be
used as an unqualified name to refer to the same entity.

</BLOCKQUOTE>

<P>Because (except in class scope) a name cannot be used before
it is declared, this definition contradicts the statement in the
example and many other uses of the term throughout the Standard.
As it stands, this definition is identical to that of the scope
of a name.</P>

<P>The term &#8220;scope&#8221; is also misused.  The scope of a
declaration is defined in 3.3 [basic.scope] paragraph 1 as
the region in which the name being declared is valid.  However, there
is frequent use of the phrase &#8220;the scope of a class,&#8221; not
referring to the region in which the class's name is valid but to the
declarative region of the class body, and similarly for namespaces,
functions, exception handlers, etc.  There is even a mention of
looking up a name &#8220;in the scope of the
complete <I>postfix-expression</I>&#8221; (3.4.5 [basic.lookup.classref] paragraph 3), which is the exact inverse of the scope
of a declaration.</P>

<P>This terminology needs a thorough review to make it logically
consistent.  (Perhaps a discussion of the scope of template
parameters could also be added to section 3.3 [basic.scope]
at the same time, as all other kinds of scopes are described there.)</P>

<P><B>Proposed resolution (November, 2006):</B></P>

<OL>
<LI><P>Change 3.3 [basic.scope] paragraph 1 as follows:
</P></LI>

<BLOCKQUOTE>

Every name is introduced in some portion of program text called a
<I>declarative region</I>, which is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the largest part of the
program in which that name is <I>valid</I>, that is, in which
that name may be used as an unqualified name to refer to the same
entity</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a <I>statement</I>, block, function declarator,
<I>function-definition</I>, class, handler, <I>template-declaration</I>,
<I>template-parameter-list</I> of a template
<I>template-parameter</I>, or namespace</SPAN>. In general, each
particular name <SPAN style="text-decoration:line-through;background-color:#FFA0A0">is valid</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">may be used as an unqualified
name to refer to the entity of its declaration or to the
label</SPAN> only within some possibly discontiguous portion of
program text called its <I>scope</I>. To determine the scope of a
declaration...

</BLOCKQUOTE>

<LI><P>Change 3.3 [basic.scope] paragraph 3 as follows:
</P></LI>

<BLOCKQUOTE>

The names declared by a declaration are introduced into the
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">scope in which the declaration occurs</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">declarative
region that directly encloses the declaration</SPAN>, except that
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>declaration-statement</I>s, function parameter names in the
declarator of a <I>function-definition</I>,
<I>exception-declaration</I>s (3.3.3 [basic.scope.block]),</SPAN>
the presence of a <TT>friend</TT> specifier (11.3 [class.friend]), certain uses of the
<I>elaborated-type-specifier</I> (7.1.6.3 [dcl.type.elab]),
and <I>using-directive</I>s (7.3.4 [namespace.udir]) alter
this general behavior.

</BLOCKQUOTE>

<LI><P>Change 3.3.3 [basic.scope.block] paragraphs 1-3 and add a
new paragraph 4 before the existing paragraph 4 as follows:
</P></LI>

<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">A name declared in a block (6.3 [stmt.block]) is
local to that block. Its potential scope begins at its point of
declaration (3.3.2 [basic.scope.pdecl]) and ends at the end of
its declarative region.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">The declarative region of a name
declared in a <I>declaration-statement</I> is the directly
enclosing block (6.3 [stmt.block]). Such a name is local
to the block.</SPAN></P>

<P>The <SPAN style="text-decoration:line-through;background-color:#FFA0A0">potential scope</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">declarative region</SPAN> of a
function parameter name <SPAN style="text-decoration:line-through;background-color:#FFA0A0">(including one appearing </SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">in
the declarator of a <I>function-definition</I> or</SPAN> in a
<I>lambda-parameter-declaration-clause</I><SPAN style="text-decoration:line-through;background-color:#FFA0A0">)</SPAN> or of a
function-local predefined variable in a function definition
(8.4 [dcl.fct.def]) <SPAN style="text-decoration:line-through;background-color:#FFA0A0">begins at its point of
declaration. If the function has a <I>function-try-block</I> the
potential scope of a parameter or of a function-local predefined
variable ends at the end of the last associated handler,
otherwise it ends at the end of the outermost block of the
function definition. A parameter name</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is the entire
function definition or <I>lambda-expression</I>. Such a name is
local to the function definition and</SPAN> shall not be redeclared
in <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">any</SPAN> outermost block of the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">function
definition nor in the outermost block of any handler associated
with a <I>function-try-block</I></SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>function-body</I> (including handlers of a
<I>function-try-block</I>) or <I>lambda-expression</I></SPAN>.</P>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">The name in a <TT>catch</TT> exception-declaration</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">The declarative region of a name declared in an
<I>exception-declaration</I> is its entire handler. Such a
name</SPAN> is local to the handler and shall not be redeclared in
the outermost block of the handler.</P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">The potential scope of any local name begins at its point
of declaration (3.3.2 [basic.scope.pdecl]) and ends at the end
of its declarative region.</SPAN></P>

</BLOCKQUOTE>

<LI><P>Change 3.3.5 [basic.funscope] as indicated:
</P></LI>

<BLOCKQUOTE>

Labels (6.1 [stmt.label]) have <I>function scope</I> and
may be used anywhere in the function in which they are declared
<SPAN style="font-weight:bold;background-color:#A0FFA0">except in members of local classes (9.8 [class.local])
of that function</SPAN>. Only labels have function scope.

</BLOCKQUOTE>

<LI><P>Change 6.7 [stmt.dcl] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<P>A declaration statement introduces one or more new <SPAN style="text-decoration:line-through;background-color:#FFA0A0">identifiers</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">names</SPAN> into a block; it has the form</P>

<UL>
<I>declaration-statement:</I>
<UL>
<I>block-declaration</I>
</UL></UL>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I></SPAN> If <SPAN style="text-decoration:line-through;background-color:#FFA0A0">an identifier</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a name</SPAN>
introduced by a declaration was previously declared in an outer
block, the outer declaration is hidden for the remainder of the
block, after which it resumes its force <SPAN style="font-weight:bold;background-color:#A0FFA0">(3.3.10 [basic.scope.hiding])</SPAN>. <SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end note</I>]</SPAN></P>

</BLOCKQUOTE>
</OL>

<P><I>[Drafting notes: This resolution deals almost exclusively
with the unclear definition of &#8220;declarative region.&#8221;
I've left the ambiguous use of &#8220;scope&#8221; alone for now.
However sections 3.3.x all have headings reading &#8220;xxx
scope,&#8221; but they don't mean the scope of a declaration but
the different kinds of declarative regions and their effects on
the scope of declarations contained therein. To me, it looks like
most of 3.4 should refer to &#8220;declarative region&#8221; and
not to &#8220;scope.&#8221;</I></P>

<P><I>The change to 6.7 fixes an &#8220;identifier&#8221; misuse
(e.g., <TT>extern T operator+(T,T);</TT> at block scope
introduces a name but not an identifier) and removes normative
redundancy.]</I></P>

<BR><BR><HR><A NAME="555"></A><H4>555.
  
Pseudo-destructor name lookup
</H4><B>Section: </B>3.4&#160; [basic.lookup]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Krzysztof Zelechowski
 &#160;&#160;&#160;

 <B>Date: </B>26 January 2006<BR>


<P>The Standard does not completely specify how to look up the
<I>type-name</I>(s) in a <I>pseudo-destructor-name</I> (5.2 [expr.post] paragraph 1, 5.2.4 [expr.pseudo]), and what
information it does have is incorrect and/or in the wrong place.
Consider, for instance, 3.4.5 [basic.lookup.classref] paragraphs
2-3:</P>

<BLOCKQUOTE>

<P>If the <I>id-expression</I> in a class member access (5.2.5 [expr.ref]) is an <I>unqualified-id</I>, and the type of the
object expression is of a class type <TT>C</TT> (or of pointer to a
class type <TT>C</TT>), the <I>unqualified-id</I> is looked up in the scope
of class <TT>C</TT>. If the type of the object expression is of pointer to
scalar type, the <I>unqualified-id</I> is looked up in the context of the
complete <I>postfix-expression</I>.</P>

<P>If the <I>unqualified-id</I> is <TT>~</TT><I>type-name</I>, and the
type of the object expression is of a class type <TT>C</TT> (or of
pointer to a class type <TT>C</TT>), the <I>type-name</I> is looked up
in the context of the entire <I>postfix-expression</I> and in the
scope of class <TT>C</TT>. The <I>type-name</I> shall refer to
a <I>class-name</I>. If <I>type-name</I> is found in both contexts,
the name shall refer to the same class type. If the type of the object
expression is of scalar type, the <I>type-name</I> is looked up in the
scope of the complete <I>postfix-expression</I>.</P>

</BLOCKQUOTE>

<P>There are at least three things wrong with this passage with
respect to pseudo-destructors:</P>

<OL>

<LI><P>A pseudo-destructor call (5.2.4 [expr.pseudo]) is not
a &#8220;class member access&#8221;, so the statements about scalar
types in the object expressions are vacuous: the object expression in
a class member access is required to be a class type or pointer to
class type (5.2.5 [expr.ref] paragraph 2).</P></LI>

<LI><P>On a related note, the lookup for the <I>type-name</I>(s) in a
pseudo-destructor name should not be described in a section entitled
&#8220;Class member access.&#8221;</P></LI>

<LI><P>Although the class member access object expressions are
carefully allowed to be either a class type or a pointer to a class
type, paragraph 2 mentions only a &#8220;pointer to scalar type&#8221;
(disallowing references) and paragraph 3 deals only with a
&#8220;scalar type,&#8221; presumably disallowing pointers (although
it could possibly be a very subtle way of referring to both non-class
pointers and references to scalar types at once).</P></LI>

</OL>

<P>The other point at which lookup of pseudo-destructors is
mentioned is 3.4.3 [basic.lookup.qual] paragraph 5:</P>

<BLOCKQUOTE>

If a <I>pseudo-destructor-name</I> (5.2.4 [expr.pseudo])
contains a <I>nested-name-specifier</I>, the <I>type-name</I>s are
looked up as types in the scope designated by the
<I>nested-name-specifier</I>.

</BLOCKQUOTE>

<P>Again, this specification is in the wrong location (a
<I>pseudo-destructor-name</I> is not a <I>qualified-id</I> and
thus should not be treated in the &#8220;Qualified name lookup&#8221;
section).</P>

<P>Finally, there is no place in the Standard that describes the
lookup for pseudo-destructor calls of the form
<TT>p-&gt;T::~T()</TT> and <TT>r.T::~T()</TT>, where <TT>p</TT>
and <TT>r</TT> are a pointer and reference to scalar, respectively.
To the extent that it gives any guidance at all,
3.4.5 [basic.lookup.classref] deals only with the case where the
<TT>~</TT> immediately follows the <TT>.</TT> or <TT>-&gt;</TT>, and
3.4.3 [basic.lookup.qual] deals only with the case where the
<I>pseudo-destructor-name</I> contains
a <I>nested-name-specifier</I> that designates a scope in which
names can be looked up.</P>

<P>See document J16/06-0008 = WG21 N1938 for further discussion of
this and related issues, including <A HREF="
     cwg_defects.html#244">244</A>,
<A HREF="
     cwg_defects.html#305">305</A>, <A HREF="
     cwg_active.html#399">399</A>,
and <A HREF="
     cwg_defects.html#414">414</A>.</P>

<P><B>Proposed resolution (June, 2008):</B></P>

<OL><LI><P>Add a new paragraph following 5.2 [expr.post]
paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

When a <I>postfix-expression</I> is followed by a dot <TT>.</TT> or
arrow <TT>-&gt;</TT> operator, the interpretation depends on the type
<TT>T</TT> of the expression preceding the operator. If the operator
is <TT>.</TT>, <TT>T</TT> shall be a scalar type or a complete class
type; otherwise, <TT>T</TT> shall be a pointer to a scalar type or a
pointer to a complete class type. When <TT>T</TT> is a (pointer to) a
scalar type, the <I>postfix-expression</I> to which the operator
belongs shall be a pseudo-destructor call (5.2.4 [expr.pseudo]); otherwise, it shall be a class member access
(5.2.5 [expr.ref]).

</BLOCKQUOTE>

<LI><P>Change 5.2.4 [expr.pseudo] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">The left-hand side of the dot operator shall be of scalar type. The
left-hand side of the arrow operator shall be of pointer to scalar
type. This scalar type</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">The type of the expression preceding the dot
operator, or the type to which the expression preceding the arrow
operator points,</SPAN> is the object type...

</BLOCKQUOTE>

<LI><P>Change 5.2.5 [expr.ref] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

For the first option (dot) the type of the first expression (the
object expression) <SPAN style="text-decoration:line-through;background-color:#FFA0A0">shall be &#8220;class object&#8221; (of a
complete type)</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is a class type</SPAN>. For the second option
(arrow) the type of the first expression (the pointer expression)
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">shall be &#8220;pointer to class object&#8221; (of a complete
type)</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is a pointer to a class type</SPAN>. In these cases, the
<I>id-expression</I> shall name a member of the class or of one of its
base classes.

</BLOCKQUOTE>

<LI><P>Add a new paragraph following 3.4 [basic.lookup]
paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

In a <I>pseudo-destructor-name</I> that does not include a
<I>nested-name-specifier</I>, the <I>type-name</I>s are looked up as
types in the context of the complete expression.

</BLOCKQUOTE>

<LI><P>Delete the last sentence of 3.4.5 [basic.lookup.classref]
paragraph 2:</P></LI>

<BLOCKQUOTE>

If the <I>id-expression</I> in a class member access (5.2.5 [expr.ref]) is an <I>unqualified-id</I>, and the type of the object
expression is of a class type <TT>C</TT>, the
<I>unqualified-id</I> is looked up in the scope of class
<TT>C</TT>. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">If the type of the object expression is of pointer to
scalar type, the <I>unqualified-id</I> is looked up in the
context of the complete <I>postfix-expression</I>.</SPAN>

</BLOCKQUOTE>

</OL>

<P><B>Notes from the August, 2011 meeting:</B></P>

<P>The proposed resolution must be updated with respect to the current
wording of the WP.</P>

<BR><BR><HR><A NAME="192"></A><H4>192.
  
Name lookup in parameters
</H4><B>Section: </B>3.4.1&#160; [basic.lookup.unqual]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Alan Nash
 &#160;&#160;&#160;

 <B>Date: </B>6 Jan 2000<BR>





<P>The description of name lookup in the
<I>parameter-declaration-clause</I> of member functions in
3.4.1 [basic.lookup.unqual]
 paragraphs 7-8 is
flawed in at least two regards.</P>

<P>First, both paragraphs 7 and 8 apply to the
<I>parameter-declaration-clause</I> of a member function definition
and give different rules for the lookup.  Paragraph 7 applies to names
"used in the definition of a class <TT>X</TT> outside of a member
function body...," which includes the
<I>parameter-declaration-clause</I> of a member function definition,
while paragraph 8 applies to names following the function's
<I>declarator-id</I> (see the proposed resolution of
<A HREF="
     cwg_defects.html#41">issue 41</A>), including the
<I>parameter-declaration-clause</I>.</P>

<P>Second, paragraph 8 appears to apply to the type names used in the
<I>parameter-declaration-clause</I> of a member function defined
inside the class definition.  That is, it appears to allow the
following code, which was not the intent of the Committee:</P>

<PRE>
    struct S {
        void f(I i) { }
        typedef int I;
    };
</PRE>

<P><B>Additional note, January, 2012:</B></P>

<P><I>brace-or-equal-initializer</I>s for non-static data members are
intended effectively as syntactic sugar for <I>mem-initializer</I>s in
constructor definitions; the lookup should be the same.</P>
<BR><BR><HR><A NAME="156"></A><H4>156.
  
Name lookup for conversion functions
</H4><B>Section: </B>3.4.5&#160; [basic.lookup.classref]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Derek Inglis
 &#160;&#160;&#160;

 <B>Date: </B>18 Aug 1999<BR>





<P>Paragraph 7 of
3.4.5 [basic.lookup.classref]
 says,</P>

<BLOCKQUOTE>
If the <I>id-expression</I> is a <I>conversion-function-id</I>, its
<I>conversion-type-id</I> shall denote the same
type in both the context in which the
entire <I>postfix-expression</I> occurs
and in the context of the class of the object
expression (or the class pointed to by the pointer expression).
</BLOCKQUOTE>

Does this mean that the following example is ill-formed?

<PRE>
    struct A { operator int(); } a;
    void foo() {
      typedef int T;
      a.operator T(); // 1) error T is not found in the context
		      // of the class of the object expression?
    }
</PRE>

The second bullet in paragraph 1 of 
3.4.3.1 [class.qual]
 says,

<BLOCKQUOTE>
a <I>conversion-type-id</I> of an
<I>operator-function-id</I> is looked up both
in the scope of the class and in the
context in which the entire <I>postfix-expression</I>
occurs and shall refer to the
same type in both contexts
</BLOCKQUOTE>

How about:

<PRE>
    struct A { typedef int T; operator T(); };
    struct B : A { operator T(); } b;
    void foo() {
      b.A::operator T(); // 2) error T is not found in the context
			 // of the postfix-expression?
    }
</PRE>

Is this interpretation correct?  Or was the intent for
this to be an error only if
<TT>T</TT> was found in both scopes and referred to different entities?

<P>If the intent was for these to be errors,
how do these rules apply to template
arguments?</P>

<PRE>
    template &lt;class T1&gt; struct A { operator T1(); }
    template &lt;class T2&gt; struct B : A&lt;T2&gt; {
      operator T2();
      void foo() {
	T2 a = A&lt;T2&gt;::operator T2(); // 3) error? when instantiated T2 is not
				     // found in the scope of the class
	T2 b = ((A&lt;T2&gt;*)this)-&gt;operator T2(); // 4) error when instantiated?
      }
    }
</PRE>

<P>(Note bullets 2 and 3 in paragraph 1 of
3.4.3.1 [class.qual]
 refer to
<I>postfix-expression</I>.  It would be better to use
<I>qualified-id</I> in both cases.)</P>

<P><U>Erwin Unruh</U>:
The intent was that you look in both contexts. If you find it only once,
that's the symbol. If you find it in both, both symbols must be "the same"
in some respect. (If you don't find it, its an error).</P>

<P><U>Mike Miller</U>:
What's not clear to me in these examples is whether what is
being looked up is <TT>T</TT> or <TT>int</TT>.
Clearly the <TT>T</TT> has to be
looked up somehow, but the "name" of a conversion function
clearly involves the base (non-typedefed) type, not typedefs
that might be used in a definition or reference (cf
3 [basic]
 paragraph 7 and
12.3 [class.conv]
 paragraph 5).
(This is true even for types that must be written
using typedefs because of the limited syntax in
<I>conversion-type-id</I>s &#8212; e.g., the "name" of the conversion
function in the following example</P>

<PRE>
    typedef void (*pf)();
    struct S {
	operator pf();
    };
</PRE>

is <TT>S::operator void(*)()</TT>, even though you can't write its name
directly.)

<P>My guess is that this means that in each scope you look up
the type named in the reference and form the canonical
operator name; if the name used in the reference isn't found
in one or the other scope, the canonical name constructed
from the other scope is used.  These names must be identical,
and the <I>conversion-type-id</I> in the canonical operator name must
not denote different types in the two scopes (i.e., the type
might not be found in one or the other scope, but if it's found
in both, they must be the same type).</P>

<P>I think this is all very vague in the current wording.</P>
<BR><BR><HR><A NAME="682"></A><H4>682.
  
Missing description of lookup of template aliases
</H4><B>Section: </B>3.4.5&#160; [basic.lookup.classref]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>1 March, 2008<BR>


<P>3.4.5 [basic.lookup.classref] does not mention template aliases as the
possible result of the lookup but should do so.</P>

<BR><BR><HR><A NAME="1089"></A><H4>1089.
  
Template parameters in member selections
</H4><B>Section: </B>3.4.5&#160; [basic.lookup.classref]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2010-06-29<BR>




<P>In an example like</P>

<PRE>
    template&lt;typename T&gt; void f(T p)-&gt;decltype(p.T::x);
</PRE>

<P>The <I>nested-name-specifier</I> <TT>T::</TT> looks like it refers
to the template parameter.  However, if this is instantiated with a
type like</P>

<PRE>
    struct T { int x; };
    struct S: T { };
</PRE>

<P>the reference will be ambiguous, since it is looked up in both the
context of the expression, finding the template parameter, and in the
class, finding the base class injected-class-name, and this could be
a deduction failure.  As a result, the same declaration with a
different parameter name</P>

<PRE>
    template&lt;typename U&gt; void f(U p)-&gt;decltype(p.U::x);
</PRE>

<P>is, in fact, not a redeclaration because the two can be distinguished
by SFINAE.</P>

<P>It would be better to add a new lookup rule that says that if a
name in a template definition resolves to a template parameter, that
name is not subject to further lookup at instantiation time.</P>

<BR><BR><HR><A NAME="1291"></A><H4>1291.
  
Looking up a <I>conversion-type-id</I>
</H4><B>Section: </B>3.4.5&#160; [basic.lookup.classref]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2011-04-10<BR>


<P>The Standard talks about looking up a <I>conversion-type-id</I> as if
it were an identifier (3.4.5 [basic.lookup.classref] paragraph 7), but that
is not exactly accurate.  Presumably it should talk instead about looking
up names (if any) appearing in the <I>type-specifier-seq</I> of the
<I>conversion-type-id</I>.</P>

<BR><BR><HR><A NAME="426"></A><H4>426.
  
Identically-named variables, one internally and one externally linked, allowed?
</H4><B>Section: </B>3.5&#160; [basic.link]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>2 July 2003<BR>


<P>An example in
3.5 [basic.link] paragraph 6 creates two file-scope variables
with the same name,
one with internal linkage and one with external.</P>
<PRE>
  static void f();
  static int i = 0;                       //1
  void g() {
          extern void f();                // internal linkage
          int i;                          //2: i has no linkage
          {
                  extern void f();        // internal linkage
                  extern int i;           //3: external linkage
          }
  }
</PRE>
<P>Is this really what we want?
C99 has 6.2.2.7/7,
which gives undefined behavior for having an identifier appear with
internal and external linkage in the same translation unit.  C++
doesn't seem to have an equivalent.</P>

<P><B>Notes from October 2003 meeting:</B></P>

<P>We agree that this is an error.  We propose to leave the example
but change the comment to indicate that line //3 has undefined
behavior, and elsewhere add a normative rule giving such a
case undefined behavior.</P>

<P><B>Proposed resolution (October, 2005):</B></P>

<P>Change 3.5 [basic.link] paragraph 6 as indicated:</P>

<BLOCKQUOTE>

<P>...Otherwise, if no matching entity is found, the block scope entity
receives external linkage.  <SPAN style="font-weight:bold;background-color:#A0FFA0">If, within a translation unit, the same
entity is declared with both internal and external linkage, the
behavior is undefined.</SPAN></P>

<P>[<I>Example:</I></P>

<PRE>
    static void f();
    static int i = 0;            //<SPAN style="font-family:Times;font-style:italic"> 1</SPAN>
    void g () {
        extern void f ();        //<SPAN style="font-family:Times;font-style:italic"> internal linkage</SPAN>
        int i;                   //<SPAN style="font-family:Times;font-style:italic"> 2: </SPAN>i<SPAN style="font-family:Times;font-style:italic"> has no linkage</SPAN>
        {
            extern void f ();    //<SPAN style="font-family:Times;font-style:italic"> internal linkage</SPAN>
            extern int i;        //<SPAN style="font-family:Times;font-style:italic"> 3: external linkage</SPAN>
        }
    }
</PRE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">There are three objects named <TT>i</TT> in this program.  The
object with internal linkage introduced by the declaration in global
scope (line <TT>//1</TT> ), the object with automatic storage duration
and no linkage introduced by the declaration on line <TT>//2</TT>, and
the object with static storage duration and external linkage
introduced by the declaration on line <TT>//3</TT>.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">Without the
declaration at line <TT>//2</TT>, the declaration at line <TT>//3</TT>
would link with the declaration at line <TT>//1</TT>.  But because the
declaration with internal linkage is hidden, <TT>//3</TT> is given
external linkage, resulting in a linkage conflict.</SPAN> &#8212;<I>end
example</I>]</P>

</BLOCKQUOTE>

<P><B>Notes frum the April 2006 meeting:</B></P>

<P>According to 3.5 [basic.link] paragraph 9, the two
variables with linkage in the proposed example are not &#8220;the
same entity&#8221; because they do not have the same linkage.  Some other
formulation will be needed to describe the relationship between those
two variables.</P>

<P><B>Notes from the October 2006 meeting:</B></P>

<P>The CWG decided that it would be better to make a program with this
kind of linkage mismatch ill-formed instead of having undefined
behavior.</P>

<BR><BR><HR><A NAME="1669"></A><H4>1669.
  
<TT>auto</TT> return type for <TT>main</TT>
</H4><B>Section: </B>3.6.1&#160; [basic.start.main]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-26<BR>




<P>Should it be permitted for <TT>main</TT> to have a deduced return
type?</P>

<P>(See also <A HREF="
     cwg_active.html#1676">issue 1676</A>.)</P>

<BR><BR><HR><A NAME="1294"></A><H4>1294.
  
Side effects in dynamic/static initialization
</H4><B>Section: </B>3.6.2&#160; [basic.start.init]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2011-04-08<BR>




<P>According to 3.6.2 [basic.start.init] paragraph 3,</P>

<BLOCKQUOTE>

<P>An implementation is permitted to perform the initialization of a
non-local variable with static storage duration as a static
initialization even if such initialization is not required to be done
statically, provided that</P>

<UL>

<LI><P> the dynamic version of the initialization does not change the value
 of any other object of namespace scope prior to its initialization,
 and
</P></LI>

<LI><P>the static version of the initialization produces the same value in
the initialized variable as would be produced by the dynamic
initialization if all variables not required to be initialized
statically were initialized dynamically.
</P></LI>

</UL>

</BLOCKQUOTE>

<P>This does not consider side effects of the initialization in this
determination, only the values of namespace-scope variables.</P>



<BR><BR><HR><A NAME="1677"></A><H4>1677.
  
Constant initialization via aggregate initialization
</H4><B>Section: </B>3.6.2&#160; [basic.start.init]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2013-05-05<BR>




<P>The resolution of <A HREF="
     cwg_defects.html#1489">issue 1489</A> added wording
regarding value initialization to 3.6.2 [basic.start.init] paragraph
2 in an attempt to clarify the status of an example like</P>

<PRE>
  int a[1000]{};
</PRE>

<P>However, this example is aggregate initialization, not value
initialization.  Also, now that we allow <I>brace-or-equal-initializer</I>s
in aggregates, this wording also needs to be updated to allow an aggregate
with constant non-static data member initializers to qualify for constant
initialization.</P>

<BR><BR><HR><A NAME="1634"></A><H4>1634.
  
Temporary storage duration
</H4><B>Section: </B>3.7&#160; [basic.stc]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-03-04<BR>




<P>According to 3.7 [basic.stc] paragraph 2,</P>

<BLOCKQUOTE>

Static, thread, and automatic storage durations are associated with objects
introduced by declarations (3.1 [basic.def]) and implicitly
created by the implementation (12.2 [class.temporary]).

</BLOCKQUOTE>

<P>The apparent intent of the reference to 12.2 [class.temporary] is
that a temporary whose lifetime is extended to be that of a reference with
one of those storage durations is considered also to have that storage
duration.  This interpretation is buttressed by use of the phrase &#8220;an
object with the same storage duration as the temporary&#8221; (twice) in
12.2 [class.temporary] paragraph 5.</P>

<P>There are two problems, however: first, the specification of lifetime
extension of temporaries (also in 12.2 [class.temporary] paragraph 5)
does not say anything about storage duration.  Also, nothing is said in
either of these locations about the storage duration of a temporary whose
lifetime is not extended.</P>

<P>The latter point is important because 3.8 [basic.life] makes
a distinction between the lifetime of an object and the acquisition and
release of the storage the object occupies, at least for objects with
non-trivial initialization and/or a non-trivial destructor.  The
assumption is made in 12.2 [class.temporary] and elsewhere that the
storage in which a temporary is created is no longer available for
reuse, as specified in 3.8 [basic.life], after the lifetime of
the temporary has ended, but this assumption is not explicitly stated.
One way to make that assumption explicit would be to define a storage
duration for temporaries whose lifetime is not extended.</P>

<BR><BR><HR><A NAME="1338"></A><H4>1338.
  
Aliasing and allocation functions
</H4><B>Section: </B>3.7.4.1&#160; [basic.stc.dynamic.allocation]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2011-08-03<BR>




<P>In 3.7.4.1 [basic.stc.dynamic.allocation] paragraph 2, allocation functions
are constrained to return a pointer that is different from any previously
returned pointer that has not been passed to a deallocation function.
This does not, for instance, prohibit returning a pointer to storage that
is part of another object, for example, a pool of storage.  The potential
implications of this for aliasing should be spelled out.</P>

<P>(See also issues <A HREF="
     cwg_active.html#1027">1027</A> and
<A HREF="
     cwg_active.html#1116">1116</A>.)</P>

<P><B>Additional note (March, 2013):</B></P>

<P>One possibility to allow reasonable optimizations would be to require
that allocation packages hide their storage in file-static variables,
perhaps by adding wording such as:</P>

<BLOCKQUOTE>

Furthermore, <TT>p0</TT> shall point to an object distinct from any other
object that is accessible outside the implementation of the allocation and
deallocation functions.

</BLOCKQUOTE>



<P><B>Additional note, April, 2013:</B></P>

<P>Concern was expressed that a pool class might provide an
interface for iterating over all the pointers that were given out
from the pool, and this usage should be supported.
</P>

<P><B>Notes from the September, 2013 meeting:</B></P>

<P>CWG agreed that changes for this issue should apply only to
non-placement forms.</P>

<BR><BR><HR><A NAME="1676"></A><H4>1676.
  
<TT>auto</TT> return type for allocation and deallocation functions
</H4><B>Section: </B>3.7.4.1&#160; [basic.stc.dynamic.allocation]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-05-04<BR>




<P>Do we need explicit language to forbid <TT>auto</TT> as the return type
of allocation and deallocation functions?</P>

<P>(See also <A HREF="
     cwg_active.html#1669">issue 1669</A>.)</P>

<BR><BR><HR><A NAME="1027"></A><H4>1027.
  
Type consistency and reallocation of scalar types
</H4><B>Section: </B>3.8&#160; [basic.life]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Gabriel Dos Reis
 &#160;&#160;&#160;

 <B>Date: </B>2010-02-03<BR>




<P>Is the following well-formed?</P>

<PRE>
    int f() {
        int i = 3;
        new (&amp;i) float(1.2);
        return i;
    }
</PRE>

<P>The wording that is intended to prevent such shenanigans,
3.8 [basic.life] paragraphs 7-9, doesn't quite apply here.
In particular, paragraph 7 reads,</P>

<BLOCKQUOTE>

<P>If, after the lifetime of an object has ended and before the
storage which the object occupied is reused or released, a new
object is created at the storage location which the original
object occupied, a pointer that pointed to the original object, a
reference that referred to the original object, or the name of
the original object will automatically refer to the new object
and, once the lifetime of the new object has started, can be used
to manipulate the new object, if:</P>

<UL><LI><P>the storage for the new object exactly overlays the
storage location which the original object occupied, and</P></LI>

<LI><P>the new object is of the same type as the original object
(ignoring the top-level cv-qualifiers), and...</P></LI>

</UL>

</BLOCKQUOTE>

<P>The problem here is that this wording only applies
&#8220;<B>after</B> the lifetime of an object has ended and
<B>before</B> the storage which the object occupied is
reused;&#8221; for an object of a scalar type, its lifetime only
ends <I>when</I> the storage is reused or released (paragraph 1),
so it appears that these restrictions cannot apply to such
objects.</P>

<P>(See also issues <A HREF="
     cwg_active.html#1116">1116</A> and
<A HREF="
     cwg_active.html#1338">1338</A>.)</P>

<P><B>Proposed resolution (August, 2010):</B></P>

<P>This issue is resolved by the resolution of
<A HREF="
     cwg_active.html#1116">issue 1116</A>.</P>

<BR><BR><HR><A NAME="1116"></A><H4>1116.
  
Aliasing of union members
</H4><B>Section: </B>3.8&#160; [basic.life]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>US
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-02<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3296.html#US27">N3092 comment
  US&#160;27<BR></A>

<P>Related to <A HREF="
     cwg_active.html#1027">issue 1027</A>, consider:</P>

<PRE>
    int f() {
      union U { double d; } u1, u2;
      (int&amp;)u1.d = 1;
      u2 = u1;
      return (int&amp;)u2.d;
    }
</PRE>

<P>Does this involve undefined behavior? 3.8 [basic.life] paragraph 4 seems to say that it's OK to clobber
<TT>u1</TT> with an <TT>int</TT> object. Then union
assignment copies the object representation, possibly
creating an <TT>int</TT> object in <TT>u2</TT> and making
the return statement well-defined. If this is well-defined,
compilers are significantly limited in the assumptions they
can make about type aliasing. On the other hand, the variant
where <TT>U</TT> has an array of <TT>unsigned char</TT>
member must be well-defined in order to support
<TT>std::aligned_storage</TT>.</P>

<P><U>Suggested resolution</U>: Clarify that this case is
undefined, but that adding an array of <TT>unsigned
char</TT> to union <TT>U</TT> would make it well-defined
&#8212; if a storage location is allocated with a particular
type, it should be undefined to create an object in that
storage if it would be undefined to access the stored value
of the object through the allocated type.</P>

<P>(See also issues <A HREF="
     cwg_active.html#1027">1027</A> and
<A HREF="
     cwg_active.html#1338">1338</A>.)</P>

<P><B>Proposed resolution (August, 2010):</B></P>

<OL><LI><P>Change 3.8 [basic.life] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<P>...The lifetime of an object of type <TT>T</TT> begins when
<SPAN style="font-weight:bold;background-color:#A0FFA0">storage with the proper alignment and size for type <TT>T</TT>
is obtained, and either</SPAN>:</P>

<UL><LI><SPAN style="text-decoration:line-through;background-color:#FFA0A0">storage with the proper alignment and size for type
<TT>T</TT> is obtained, and</SPAN></LI>

<LI><P>if the object has non-trivial initialization, its
initialization is complete<SPAN style="text-decoration:line-through;background-color:#FFA0A0">.</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">, or</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if <TT>T</TT> is trivially copyable, the object representation
of another <TT>T</TT> object is copied into the storage.</SPAN></P></LI>

</UL>

<P>The lifetime of an object of type <TT>T</TT> ends...</P>

</BLOCKQUOTE>

<LI><P>Change 3.8 [basic.life] paragraph 4 as follows:</P></LI>

<BLOCKQUOTE>

<P>A program may end the lifetime of any object by reusing
the storage which the object occupies or by explicitly
calling the destructor for an object of a class type with a
non-trivial destructor.  For an object of a class type with
a non-trivial destructor, the program is not required to
call the destructor explicitly before the storage which the
object occupies is reused or released; however, if there is
no explicit call to the destructor or if a
<I>delete-expression</I> (5.3.5 [expr.delete]) is not
used to release the storage, the destructor shall not be
implicitly called and any program that depends on the side
effects produced by the destructor has undefined
behavior. <SPAN style="font-weight:bold;background-color:#A0FFA0">If a program obtains storage for an object of
a particular type <TT>A</TT> (e.g. with a variable definition or
<I>new-expression</I>) and later reuses that storage for an
object of another type <TT>B</TT> such that accessing the
stored value of the <TT>B</TT> object through a glvalue of
type <TT>A</TT> would have undefined behavior (3.10 [basic.lval]), the behavior is undefined. [<I>Example:</I>
</SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  int i;
  (double&amp;)i = 1.0; //<SPAN style="font-family:Times;font-style:italic"> undefined behavior</SPAN>

  struct S { unsigned char alignas(double) ar[sizeof (double)]; } s;
  (double&amp;)s = 1.0; //<SPAN style="font-family:Times;font-style:italic"> OK, can access stored </SPAN>double<SPAN style="font-family:Times;font-style:italic"> through </SPAN>s<SPAN style="font-family:Times;font-style:italic"> because it has an </SPAN>unsigned char<SPAN style="font-family:Times;font-style:italic"> subobject</SPAN></SPAN>
</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end example</I>]</SPAN></P>

</BLOCKQUOTE>

<LI><P>Change 3.10 [basic.lval] paragraph 10 as follows:</P></LI>

<BLOCKQUOTE>

If a program attempts to access the stored value of an
object through a glvalue of other than one of the following
types the behavior is undefined<SUP>52</SUP><SPAN style="font-weight:bold;background-color:#A0FFA0">:</SPAN>

<UL><LI><P>the dynamic type of the object,</P></LI>

<LI><P>a cv-qualified version of the dynamic type of the
object,</P></LI>

<LI><P>a type similar (as defined in 4.4 [conv.qual]) to the dynamic type of the object,</P></LI>

<LI><P>a type that is the signed or unsigned type
corresponding to the dynamic type of the object,</P></LI>

<LI><P>a type that is the signed or unsigned type
corresponding to a cv-qualified version of the dynamic type
of the object,</P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">a <TT>char</TT> or <TT>unsigned char</TT> type,</SPAN></P></LI>

<LI><P>an aggregate or union type that includes one of the
aforementioned types among its elements<SPAN style="font-weight:bold;background-color:#A0FFA0">, bases,</SPAN>
or non-static data members (including, recursively, an
element<SPAN style="font-weight:bold;background-color:#A0FFA0">, base,</SPAN> or non-static data member of a
subaggregate<SPAN style="font-weight:bold;background-color:#A0FFA0">, base,</SPAN> or contained
union)<SPAN style="text-decoration:line-through;background-color:#FFA0A0">,</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">.</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">a type that is a (possibly cv-qualified) base class
type of the dynamic type of the object,</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">a <TT>char</TT> or <TT>unsigned char</TT> type.</SPAN></P></LI>

</UL>

</BLOCKQUOTE>

</OL>

<P>This resolution also resolves <A HREF="
     cwg_active.html#1027">issue 1027</A>.</P>

<P><B>Additional note (August, 2012):</B></P>

<P>Concerns have been raised 
regarding the interaction of this change with facilities like
<TT>std::aligned_storage</TT> and memory pools. Care must be taken
to achieve the proper balance between supporting type-based optimization
techniques and allowing practical storage management.</P>

<P><B>Additional note (January, 2013):</B></P>

<P>Several questions have been raised about the wording above
.  In
particular:</P>

<OL><LI><P>Since aggregates and unions cannot have base classes, why
are base classes mentioned?</P></LI>

<LI><P>Since unions can now have special member functions, is it still
valid to assume that they alias all their member types?</P></LI>

<LI><P>Shouldn't standard-layout classes also be considered and not
just aggregates?</P></LI>

</OL>

<BR><BR><HR><A NAME="1284"></A><H4>1284.
  
Should the lifetime of an array be independent of that of its elements?
</H4><B>Section: </B>3.8&#160; [basic.life]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Gabriel Dos Reis
 &#160;&#160;&#160;

 <B>Date: </B>2011-04-02<BR>




<P>The note in 3.8 [basic.life] paragraph 2 reads,</P>

<BLOCKQUOTE>

[<I>Note:</I> The lifetime of an array object starts as soon as
storage with proper size and alignment is obtained, and its lifetime
ends when the storage which the array occupies is reused or released.
12.6.2 [class.base.init] describes the lifetime of base and member
subobjects.  &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>This wording reflects an earlier version of paragraph 1 that
deferred the start of an object's lifetime only for initialization of
objects of class type. The note simply emphasized the implication that
that the lifetime of a POD type or an array began immediately, even if
lifetime of an array's elements began later.</P>

<P>The decomposition of POD types removed the mention of PODs, leaving
only the array types, and when the normative text was changed to
include aggregates whose members have non-trivial initialization, the
note was overlooked.</P>

<P>It is not clear whether it would be better to update the note to
emphasize the distinction between aggregates with non-trivial
initialization and those without or to delete it entirely.</P>

<P>A possible related normative change to consider is whether the
specification of paragraph 1 is sufficiently clear with respect to
multidimensional arrays.  The current definition of &#8220;non-trivial
initialization&#8221; is:</P>

<BLOCKQUOTE>

An object is said to have non-trivial initialization if it is of a
class or aggregate type and it or one of its members is initialized by
a constructor other than a trivial default constructor.

</BLOCKQUOTE>

<P>Presumably the top-level array of an N-dimensional array whose
ultimate element type is a class type with non-trivial initialization
would also have non-trivial initialization, but it's not clear that
this wording says that.</P>

<P>A more radical change that came up in the discussion was whether the
undefined behavior resulting from an lvalue-to-rvalue conversion of an
uninitialized object in 4.1 [conv.lval] paragraph 1 would be
better dealt with as a lifetime violation instead.</P>

<BR><BR><HR><A NAME="1530"></A><H4>1530.
  
Member access in out-of-lifetime objects
</H4><B>Section: </B>3.8&#160; [basic.life]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Howard Hinnant
 &#160;&#160;&#160;

 <B>Date: </B>2012-07-26<BR>




<P>According to 3.8 [basic.life] paragraphs 5 and 6, a program
has undefined behavior if a pointer or glvalue designating an
out-of-lifetime object</P>

<BLOCKQUOTE>

is used to access a non-static data member or call a non-static member
function of the object

</BLOCKQUOTE>

<P>It is not clear what the word &#8220;access&#8221; means in this
context.  A reasonable interpretation might be using the pointer or
glvalue as the left operand of a class member access expression;
alternatively, it might mean to read or write the value of that
member, allowing a class member access expression that is used only
to form an address or bind a reference.</P>

<P>This needs to be clarified.  A relevant consideration is the
recent adoption of the resolution of <A HREF="
     cwg_defects.html#597">issue 597</A>,
which eased the former restriction on simple address manipulations
involving out-of-lifetime objects: if base-class offset calculations
are now allowed, why not non-static data member offset calculations?</P>

<P>(See also <A HREF="
     cwg_defects.html#1531">issue 1531</A> for other uses of
the term &#8220;access.&#8221;)</P>

<P><B>Additional note (January, 2013):</B></P>

<P>A related question is the meaning of the phrase
&#8220;before the constructor begins execution&#8221; in
12.7 [class.cdtor] paragraph 1 means:</P>

<BLOCKQUOTE>

For an object with a non-trivial constructor, referring to any
non-static member or base class of the object before the constructor
begins execution results in undefined behavior.

</BLOCKQUOTE>

<P>For example:</P>

<PRE>
  struct DerivedMember { ... };

  struct Base {
    Base(DerivedMember const&amp;);
  };

  struct Derived : Base {
    DerivedMember x;
    Derived() : Base(x) {}
  };

  Derived a;
</PRE>

<P>Is the reference to <TT>Derived::x</TT> in the <I>mem-initializer</I>
valid?</P>

<P><B>Additional note (March, 2013):</B></P>

<P>This clause is phrased in terms of the execution of the constructor.
However, it is possible for an aggregate to have a non-trivial default
constructor and be initialized without executing a constructor.  The
wording needs to be updated to allow for non-constructor initialization
to avoid appearing to imply undefined behavior for an example like:</P>

<PRE>
  struct X {
    std::string s;
  } x = {};
  std::string t = x.s;  //<SPAN style="font-family:Times;font-style:italic"> No constructor called for </SPAN>x<SPAN style="font-family:Times;font-style:italic">: undefined behavior?</SPAN>
</PRE>

<BR><BR><HR><A NAME="1701"></A><H4>1701.
  
Array vs sequence in object representation
</H4><B>Section: </B>3.9&#160; [basic.types]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Lawrence Crowl
 &#160;&#160;&#160;

 <B>Date: </B>2013-06-14<BR>


<P>According to 3.9 [basic.types] paragraph 4,</P>

<BLOCKQUOTE>

The object representation of an object of type <TT>T</TT> is the sequence
of <I>N</I> <TT>unsigned char</TT> objects taken up by the object of
type <TT>T</TT>, where <I>N</I> equals <TT>sizeof(T)</TT>.

</BLOCKQUOTE>

<P>However, it is not clear that a &#8220;sequence&#8221; can be indexed,
as an array can and as is required for the implementation of
<TT>memcpy</TT> and similar code.</P>

<BR><BR><HR><A NAME="636"></A><H4>636.
  
Dynamic type of objects and aliasing
</H4><B>Section: </B>3.10&#160; [basic.lval]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Gabriel Dos Reis
 &#160;&#160;&#160;

 <B>Date: </B>23 May 2007<BR>




<P>The aliasing rules given in 3.10 [basic.lval] paragraph
10 rely on the concept of &#8220;dynamic type.&#8221;  The problem is
that the dynamic type of an object often cannot be determined (or
even sufficiently constrained) at the point at which an optimizer
needs to be able to determine whether aliasing might occur or not.
For example, consider the function</P>

<PRE>
    void foo(int* p, double* q) {
        *p = 42;
        *q = 3.14;
    }
</PRE>

<P>An optimizer, on the basis of the existing aliasing rules, might
decide that an <TT>int*</TT> and a <TT>double*</TT> cannot
refer to the same object and reorder the assignments.  This
reordering, however, could result in undefined behavior if the
function <TT>foo</TT> is called as follows:</P>

<PRE>
   void goo() {
      union {
         int i; 
         double d;
      } t;

      t.i = 12;

      foo(&amp;t.i, &amp;t.d);

      cout &lt;&lt; t.d &lt;&lt; endl;
   };
</PRE>

<P>Here, the reference to <TT>t.d</TT> after the call to
<TT>foo</TT> will be valid only if the assignments in
<TT>foo</TT> are executed in the order in which they were
written; otherwise, the union will contain an <TT>int</TT>
object rather than a <TT>double</TT>.</P>

<P>One possibility would be to require that if such aliasing
occurs, it be done only via member names and not via
pointers.</P>

<P><B>Notes from the July, 2007 meeting:</B></P>

<P>This is the same issue as C's <A href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_236.htm">DR236</A>.
The CWG expressed a desire to address the issue the same way C99
does.  The issue also occurs in C++ when placement new is used to
end the lifetime of one object and start the lifetime of a different
object occupying the same storage.</P>

<BR><BR><HR><A NAME="1211"></A><H4>1211.
  
Misaligned lvalues
</H4><B>Section: </B>3.11&#160; [basic.align]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>David Svoboda
 &#160;&#160;&#160;

 <B>Date: </B>2010-10-20<BR>




<P>3.11 [basic.align] speaks of &#8220;alignment
requirements,&#8221; and 3.7.4.1 [basic.stc.dynamic.allocation] requires
the result of an allocation function to point to &#8220;suitably
aligned&#8221; storage, but there is no explicit statement of
what happens when these requirements are violated (presumably
undefined behavior).</P>

<BR><BR><HR><A NAME="617"></A><H4>617.
  
Lvalue-to-rvalue conversions of uninitialized <TT>char</TT> objects
</H4><B>Section: </B>4.1&#160; [conv.lval]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Alan Stokes
 &#160;&#160;&#160;

 <B>Date: </B>6 February 2007<BR>




<P>According to 4.1 [conv.lval] paragraph 1, applying the
lvalue-to-rvalue conversion to any uninitialized object results in
undefined behavior.  However, character types are intended to allow
any data, including uninitialized objects and padding, to be copied
(hence the statements in 3.9.1 [basic.fundamental] paragraph 1
that &#8220;For character types, all bits of the object representation
participate in the value representation&#8221; and in
3.10 [basic.lval] paragraph 15 that <TT>char</TT> and
<TT>unsigned char</TT> types can alias any object).  The
lvalue-to-rvalue conversion should be permitted on uninitialized
objects of character type without evoking undefined behavior.</P>

<BR><BR><HR><A NAME="1787"></A><H4>1787.
  
Uninitialized <TT>unsigned char</TT> values
</H4><B>Section: </B>4.1&#160; [conv.lval]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>United Kingdom
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-28<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#GB2">N3690 comment
  GB&#160;2<BR></A>

<P>The current wording of 4.1 [conv.lval] gives the result of
fetching an uninitialized unsigned character an unspecified value,
which is then stable: assigned to a different variable, it will be
the same throughout the lifetime of that variable.  It would be more
helpful to optimizers for the unspecified value to be viral, so that
fetching from the second variable would also yield an unspecified
result, not necessarily the same each time.</P>

<BR><BR><HR><A NAME="170"></A><H4>170.
  
Pointer-to-member conversions
</H4><B>Section: </B>4.11&#160; [conv.mem]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Stump
 &#160;&#160;&#160;

 <B>Date: </B>16 Sep 1999<BR>





<P>The descriptions of explicit
(5.2.9 [expr.static.cast]
 paragraph 9) and
implicit (4.11 [conv.mem]
 paragraph 2)
pointer-to-member conversions differ in two significant ways:</P>

<OL>
<LI>In a <TT>static_cast</TT>, a conversion in which the class in
the target pointer-to-member type is a base of the class in which
the member is declared is permitted and required to work correctly,
as long as the resulting pointer-to-member is eventually
dereferenced with an object whose dynamic type contains the
member.  That is, the class of the target pointer-to-member type
is not required to contain the member referred to by the value
being converted.  The specification of implicit pointer-to-member
conversion is silent on this question.

<P>(This situation cannot arise in an implicit pointer-to-member
conversion where the source value is something like <TT>&amp;X::f</TT>,
since you can only implicitly convert from pointer-to-base-member
to pointer-to-derived-member.  However, if the source value is
the result of an explicit "up-cast," the target type of the
conversion might still not contain the member referred to by the
source value.)</P></LI>

<LI>The target type in a <TT>static_cast</TT> is allowed to be
more cv-qualified than the source type; in an implicit conversion,
however, the cv-qualifications of the two types are required to
be identical.</LI>
</OL>

<P>The first difference seems like an oversight.  It is not clear
whether the latter difference is intentional or not.</P>

<P>(See also <A HREF="
     cwg_closed.html#794">issue 794</A>.)</P>

<BR><BR><HR><A NAME="536"></A><H4>536.
  
Problems in the description of <I>id-expression</I>s
</H4><B>Section: </B>5.1.1&#160; [expr.prim.general]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>13 October 2005<BR>


<P>There are at least a couple of problems in the description of
the various <I>id-expression</I>s in 5.1.1 [expr.prim.general]:</P>

<OL><LI><P>Paragraph 4 embodies an incorrect assumption about the
syntax of <I>qualified-id</I>s:</P>

<BLOCKQUOTE>

The operator <TT>::</TT> followed by an <I>identifier</I>, a
<I>qualified-id</I>, or an <I>operator-function-id</I> is a
<I>primary-expression</I>.

</BLOCKQUOTE>

<P>The problem here is that the <TT>::</TT> is actually part of the
syntax of <I>qualified-id</I>; consequently, &#8220;<TT>::</TT> followed by...
a <I>qualified-id</I>&#8221; could be something like
&#8220;<TT>:: ::i</TT>,&#8221; which is ill-formed.  Presumably
this should say something like, &#8220;A <I>qualified-id</I> with
no <I>nested-name-specifier</I> is a <I>primary-expression</I>.&#8221;</P>
</LI>

<LI><P>More importantly, some kinds of <I>id-expression</I>s are not
described by 5.1.1 [expr.prim.general].  The structure of this
section is that the result, type, and lvalue-ness are specified for
each of the cases it covers:</P>

<UL>
<LI><P>paragraph 4 deals with <I>qualified-id</I>s that have no
<I>nested-name-specifier</I></P></LI>

<LI><P>paragraph 7 deals with bare <I>identifier</I>s and with
<I>qualified-id</I>s containing a <I>nested-name-specifier</I>
that names a class</P></LI>

<LI><P>paragraph 8 deals with <I>qualified-id</I>s containing a
<I>nested-name-specifier</I> that names a namespace</P></LI>

</UL>

<P>This treatment leaves unspecified all the non-<I>identifier</I>
<I>unqualified-id</I>s (<I>operator-function-id</I>,
<I>conversion-function-id</I>, and <I>template-id</I>), as well as
(perhaps) &#8220;<TT>::</TT> <I>template-id</I>&#8221; (it's not clear
whether the &#8220;<TT>::</TT> followed by a <I>qualified-id</I>&#8221; case
is supposed to apply to <I>template-id</I>s or not).  Note also that the
proposed resolution of <A HREF="
     cwg_defects.html#301">issue 301</A> slightly
exacerbates this problem by removing the form
of <I>operator-function-id</I> that contains
a <I>tmeplate-argument-list</I>; as a result, references like
&#8220;<TT>::operator+&lt;X&gt;</TT>&#8221; are no longer covered in
5.1.1 [expr.prim.general].</P>
</LI>

</OL>

<BR><BR><HR><A NAME="1249"></A><H4>1249.
  
Cv-qualification of nested lambda capture
</H4><B>Section: </B>5.1.2&#160; [expr.prim.lambda]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-02<BR>


<P>Consider the following example:</P>

<PRE>
    void f(int i) {
      auto l1 = [i] {
        auto l2 = [&amp;i] {
          ++i;    // Well-formed?
        };
      };
    }
</PRE>

<P>Because the <TT>l1</TT> lambda is not marked as <TT>mutable</TT>,
its <TT>operator()</TT> is <TT>const</TT>; however, it is not clear from
the wording of 5.1.2 [expr.prim.lambda] paragraph 16 whether the
captured member of the enclosing lambda is considered <TT>const</TT> or
not.</P>

<BR><BR><HR><A NAME="1468"></A><H4>1468.
  
<TT>typeid</TT>, overload resolution, and implicit lambda capture
</H4><B>Section: </B>5.1.2&#160; [expr.prim.lambda]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Doug Gregor
 &#160;&#160;&#160;

 <B>Date: </B>2012-02-08<BR>




<P>According to 5.1.2 [expr.prim.lambda] paragraph 11, a variable is
implicitly captured if it is odr-used. In the following example,</P>

<PRE>
  struct P {
   virtual ~P();
  };

  P &amp;f(int&amp;);
  int f(const int&amp;);

  void g(int x) {
   [=] {
    typeid(f(x));
   };
  }
</PRE>

<P><TT>x</TT> is only odr-used if the operand of <TT>typeid</TT> is a
polymorphic lvalue; otherwise, the operand is unevaluated
(5.2.8 [expr.typeid] paragraphs 2-3).  Whether the operand is a
polymorphic lvalue depends on overload resolution in this case, which
depends on whether <TT>x</TT> is captured or not: if <TT>x</TT> is
captured, since the lambda is not <TT>mutable</TT>, the type of
<TT>x</TT> in the body of the lambda is <TT>const int</TT>, while if
it is not captured, it is just <TT>int</TT>.  However, the <TT>const
int</TT> version of <TT>f</TT> returns <TT>int</TT> and the
<TT>int</TT> version of <TT>f</TT> returns a polymorphic lvalue,
leading to a conundrum: <TT>x</TT> is only captured if it is not
captured, and vice versa.</P>

<P><B>Notes from the October, 2012 meeting:</B></P>

<P>The approach favored by CWG was to specify that the operand of
<TT>typeid</TT> is considered to be odr-used for the purpose of
determining capture.</P>

<BR><BR><HR><A NAME="1629"></A><H4>1629.
  
Can a closure class be a literal type?
</H4><B>Section: </B>5.1.2&#160; [expr.prim.lambda]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2012-02-22<BR>


<P>The description of the characteristics of a closure class in
5.1.2 [expr.prim.lambda] leaves open the possibility that such a
class might be a literal type, although it could also be a non-literal
type.  It would probably be good to specify that a closure class is not
a literal type, in the interests of portability.</P>

<P>On a related note, it might be wise to remove the implementation
freedom to make a closure class either a POD or not a POD; it seems
only to be an invitation for portability problems with no real
advantage.</P>

<P><B>Additional note, April, 2013:</B></P>

<P>Some have expressed the opinion that such portability issues are
just &#8220;par for the course,&#8221; and that specifying these
characteristics at this point might unnecessarily limit the ability
to extend the language in desirable directions at some point in the
future.  </P>

<P><B>Proposed resolution (April, 2013):</B></P>

<P>Change 5.1.2 [expr.prim.lambda] paragraph 3 as follows:</P>

<BLOCKQUOTE>

<P>...An implementation may define the closure type differently
from what is described below provided this does not alter
the observable behavior of the program other than by
changing:</P>

<UL><LI><P>the size and/or alignment of the closure type,</P></LI>

<LI><P>whether the closure type is trivially copyable (Clause
9 [class]),</P></LI>

<LI><SPAN style="font-weight:bold;background-color:#A0FFA0">whether the closure type is a literal type
(3.9 [basic.types]),</SPAN></LI>

<LI><P>whether the closure type is a standard-layout class (Clause
9 [class]), or</P></LI>

<LI><P>whether the closure type is a POD class (Clause
9 [class]).</P></LI>

</UL>

</BLOCKQUOTE>

<P><B>Notes from the September, 2013 meeting:</B></P>

<P>At the suggestion of EWG, it was decided that closure types should
be specified as not literal, rather than being unspecified as in the
April, 2013 proposed resolution.  The issue has thus been returned to
"drafting" status.</P>

<BR><BR><HR><A NAME="1722"></A><H4>1722.
  
Should lambda to function pointer conversion function be <TT>noexcept</TT>?
</H4><B>Section: </B>5.1.2&#160; [expr.prim.lambda]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Ville Voutilainen
 &#160;&#160;&#160;

 <B>Date: </B>2013-07-31<BR>




<P>According to 5.1.2 [expr.prim.lambda] paragraph 6,</P>

<BLOCKQUOTE>

The closure type for a non-generic <I>lambda-expression</I> with
no <I>lambda-capture</I> has a public non-virtual non-explicit const
conversion function to pointer to function with C++ language linkage
(7.5 [dcl.link]) having the same parameter and return types as
the closure type's function call operator.

</BLOCKQUOTE>

<P>This does not specify whether the conversion function is
<TT>noexcept(true)</TT> or <TT>noexcept(false)</TT>.  It might be
helpful to nail that down.</P>

<BR><BR><HR><A NAME="1646"></A><H4>1646.
  
<I>decltype-specifier</I>s, abstract classes, and deduction failure
</H4><B>Section: </B>5.2.2&#160; [expr.call]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2013-03-28<BR>




<P>According to 5.2.2 [expr.call] paragraph 11,</P>

<BLOCKQUOTE>

<P>If a function call is a prvalue of object type:</P>

<UL><LI><P>if the function call is either</P></LI>

<UL><LI><P>the operand of a <I>decltype-specifier</I> or</P></LI>

<LI><P>the right operand of a comma operator that is the operand of
a <I>decltype-specifier</I>,</P></LI>

</UL>

<P>a temporary object is not introduced for the prvalue. The
type of the prvalue may be incomplete.  [<I>Note:</I> as a
result, storage is not allocated for the prvalue and it is
not destroyed; thus, a class type is not instantiated as a
result of being the type of a function call in this
context. This is true regardless of whether the expression
uses function call notation or operator notation
(13.3.1.2 [over.match.oper]). &#8212;<I>end note</I>]
[<I>Note:</I> unlike the rule for
a <I>decltype-specifier</I> that considers whether
an <I>id-expression</I> is parenthesized
(7.1.6.2 [dcl.type.simple]), parentheses have no special
meaning in this context. &#8212;<I>end note</I>]</P>

<LI>

<P>otherwise, the type of the prvalue shall be complete.</P></LI>

</UL>

</BLOCKQUOTE>

<P>Thus, an example like</P>

<PRE>
  template &lt;class T&gt; struct A: T { };
  template &lt;class T&gt; A&lt;T&gt; f(T) { return A&lt;T&gt;(); };
  decltype(f(42)) *p;
</PRE>

<P>is well-formed.  However, a function template specialization in
which the return type is an abstract class should be a deduction
failure, per 14.8.2 [temp.deduct] paragraph 8, last bullet:</P>

<UL><LI><P>...</P></LI>

<LI><P>Attempting to create a function type in which a parameter
type or the return type is an abstract class type
(10.4 [class.abstract]).</P></LI>

</UL>

<P>The requirement that the return type in a function call in a
<I>decltype-specifier</I> not be instantiated prevents the detection
of this deduction failure in an example like:</P>

<PRE>
  template &lt;class T&gt; struct A { virtual void f() = 0; };
  template &lt;class T&gt; A&lt;T&gt; f(T) { return A&lt;T&gt;(); };
  decltype(f(42)) *p;
</PRE>

<P>It is not clear how this should be resolved.</P>

<P>(See also <A HREF="
     cwg_active.html#1640">issue 1640</A>.)</P>

<BR><BR><HR><A NAME="1521"></A><H4>1521.
  
<TT>T{</TT><I>expr</I><TT>}</TT> with reference types
</H4><B>Section: </B>5.2.3&#160; [expr.type.conv]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>2012-07-10<BR>


<P>According to 5.2.3 [expr.type.conv] paragraph 4,</P>

<BLOCKQUOTE>

Similarly, a <I>simple-type-specifier</I> or <I>typename-specifier</I>
followed by a <I>braced-init-list</I> creates a temporary object of
the specified type direct-list-initialized (8.5.4 [dcl.init.list]) with the specified <I>braced-init-list</I>, and its
value is that temporary object as a prvalue.

</BLOCKQUOTE>

<P>This wording does not handle the case where <TT>T</TT> is a
reference type: it is not possible to create a temporary object of
that type, and presumably the result would be an xvalue, not a prvalue.</P>

<BR><BR><HR><A NAME="1739"></A><H4>1739.
  
Conversion of floating point to enumeration
</H4><B>Section: </B>5.2.9&#160; [expr.static.cast]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Ville Voutilainen
 &#160;&#160;&#160;

 <B>Date: </B>2013-08-18<BR>




<P>The specification of conversion from integral or enumeration type
in 5.2.9 [expr.static.cast] paragraph 10 uses the phrase
&#8220;explicitly converted,&#8221; while the description of
conversion from floating point to enumeration omits the word
&#8220;explicitly.&#8221;  Presumably these should be harmonized.</P>

<BR><BR><HR><A NAME="232"></A><H4>232.
  
Is indirection through a null pointer undefined behavior?
</H4><B>Section: </B>5.3.1&#160; [expr.unary.op]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>5 Jun 2000<BR>




<P>At least a couple of places in the IS state that indirection
through a null pointer produces undefined behavior: 1.9 [intro.execution] paragraph 4 gives "dereferencing the null pointer" as an
example of undefined behavior, and 8.3.2 [dcl.ref]
paragraph 4 (in a note) uses this supposedly undefined behavior as
justification for the nonexistence of "null references."</P>

<P>However, 5.3.1 [expr.unary.op] paragraph 1, which describes
the unary "*" operator, does <I>not</I> say that the behavior is
undefined if the operand is a null pointer, as one might expect.
Furthermore, at least one passage gives dereferencing a null pointer
well-defined behavior: 5.2.8 [expr.typeid] paragraph 2
says</P>

<BLOCKQUOTE>
If the lvalue expression is obtained by applying the unary * operator
to a pointer and the pointer is a null pointer value (4.10 [conv.ptr]), the <TT>typeid</TT> expression throws the
<TT>bad_typeid</TT> exception (18.7.3 [bad.typeid]).
</BLOCKQUOTE>

<P>This is inconsistent and should be cleaned up.</P>

<P><U>Bill Gibbons</U>:</P>

<P>At one point we agreed that dereferencing a null pointer was
<I>not</I> undefined; only using the resulting value had undefined
behavior.</P>

<P>For example:</P>

<PRE>
    char *p = 0;
    char *q = &amp;*p;
</PRE>

<P>Similarly, dereferencing a pointer to the end of an array should be
allowed as long as the value is not used:</P>

<PRE>
    char a[10];
    char *b = &amp;a[10];   // equivalent to "char *b = &amp;*(a+10);"
</PRE>

<P>Both cases come up often enough in real code that they should be
allowed.</P>

<P><U>Mike Miller</U>:</P>

<P>I can see the value in this, but it doesn't seem to be well
reflected in the wording of the Standard.  For instance, presumably
<TT>*p</TT> above would have to be an lvalue in order to be the
operand of "<TT>&amp;</TT>", but the definition of "lvalue" in
3.10 [basic.lval] paragraph 2 says that "an lvalue refers to
an object."  What's the object in <TT>*p</TT>?  If we were to allow
this, we would need to augment the definition to include the result of
dereferencing null and one-past-the-end-of-array.</P>

<P><U>Tom Plum</U>:</P>

<P>Just to add one more recollection of the intent: I was <I>very</I>
happy when (I thought) we decided that it was only the attempt to
actually fetch a value that creates undefined behavior.  The words
which (I thought) were intended to clarify that are the first three
sentences of the lvalue-to-rvalue conversion, 4.1 [conv.lval]:</P>

<BLOCKQUOTE>

An lvalue (3.10 [basic.lval]) of a non-function, non-array
type <TT>T</TT> can be converted to an rvalue.  If <TT>T</TT> is an
incomplete type, a program that necessitates this conversion is
ill-formed.  If the object to which the lvalue refers is not an object
of type <TT>T</TT> and is not an object of a type derived from
<TT>T</TT>, or if the object is uninitialized, a program that
necessitates this conversion has undefined behavior.

</BLOCKQUOTE>

<P>In other words, it is only the act of "fetching", of
lvalue-to-rvalue conversion, that triggers the ill-formed or undefined
behavior.  Simply forming the lvalue expression, and then for example
taking its address, does not trigger either of those errors.  I
described this approach to WG14 and it may have been incorporated into
C 1999.</P>

<P><U>Mike Miller</U>:</P>

<P>If we admit the possibility of null lvalues, as Tom is suggesting
here, that significantly undercuts the rationale for prohibiting "null
references" -- what is a reference, after all, but a named lvalue?  If
it's okay to create a null lvalue, as long as I don't invoke the
lvalue-to-rvalue conversion on it, why shouldn't I be able to capture
that null lvalue as a reference, with the same restrictions on its
use?</P>

<P>I am not arguing in favor of null references.  I don't want them in
the language.  What I am saying is that we need to think carefully
about adopting the permissive approach of saying that it's all right
to create null lvalues, as long as you don't use them in certain ways.
If we do that, it will be very natural for people to question why they
can't pass such an lvalue to a function, as long as the function
doesn't do anything that is not permitted on a null lvalue.
</P>

<P>If we want to allow <TT>&amp;*(p=0)</TT>, maybe we should change
the definition of "<TT>&amp;</TT>" to handle dereferenced null
specially, just as <TT>typeid</TT> has special handling, rather than
changing the definition of lvalue to include dereferenced nulls, and
similarly for the array_end+1 case.  It's not as general, but I think
it might cause us fewer problems in the long run.
</P>

<P><B>Notes from the October 2003 meeting:</B></P>

<P>See also <A HREF="
     cwg_closed.html#315">issue 315</A>, which deals with
the call of a static member function through a null pointer.</P>

<P>We agreed that the approach in the standard seems okay:
<TT>p = 0; *p;</TT> is not inherently an error.  An
lvalue-to-rvalue conversion would give it undefined behavior.</P>

<P><B>Proposed resolution (October, 2004):</B></P>

<P>(Note: the resolution of <A HREF="
     cwg_active.html#453">issue 453</A>
also resolves part of this issue.)</P>

<OL>

<LI><P>Add the indicated words to 3.10 [basic.lval]
paragraph 2:</P>

<BLOCKQUOTE>

An lvalue refers to an object or function <SPAN style="font-weight:bold;background-color:#A0FFA0">or is an empty lvalue
(5.3.1 [expr.unary.op])</SPAN>.

</BLOCKQUOTE>

</LI>

<LI><P>Add the indicated words to 5.3.1 [expr.unary.op]
paragraph 1:</P>

<BLOCKQUOTE>

The unary <TT>*</TT> operator performs <I>indirection</I>: the
expression to which it is applied shall be a pointer to an object
type, or a pointer to a function type and the result is an lvalue
referring to the object or function to which the expression
points<SPAN style="font-weight:bold;background-color:#A0FFA0">, if any. If the pointer is a null pointer value
(4.10 [conv.ptr]) or points one past the last element
of an array object (5.7 [expr.add]), the result is an
<I>empty lvalue</I> and does not refer to any object or function.
An empty lvalue is not modifiable</SPAN>.  If the type of the
expression is &#8220;pointer to <TT>T</TT>,&#8221; the type of
the result is &#8220;<TT>T</TT>.&#8221; [<I>Note:</I> a pointer to an
incomplete type (other than cv void) can be dereferenced. The
lvalue thus obtained can be used in limited ways (to initialize a
reference, for example); this lvalue must not be converted to an
rvalue, see 4.1 [conv.lval].&#8212;<I>end note</I>]

</BLOCKQUOTE>

</LI>

<LI><P>Add the indicated words to 4.1 [conv.lval]
paragraph 1:</P>

<BLOCKQUOTE>

If the object to which the lvalue refers is not an object of type
<TT>T</TT> and is not an object of a type derived from
<TT>T</TT>, or if the object is uninitialized, <SPAN style="font-weight:bold;background-color:#A0FFA0">or if the
lvalue is an empty lvalue (5.3.1 [expr.unary.op]),</SPAN> a
program that necessitates this conversion has undefined behavior.

</BLOCKQUOTE>

</LI>

<LI><P>Change 1.9 [intro.execution] as indicated:</P>

<BLOCKQUOTE>

Certain other operations are described in this International
Standard as undefined (for example, the effect of <SPAN style="text-decoration:line-through;background-color:#FFA0A0">dereferencing
the null pointer</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">division by zero</SPAN>).

</BLOCKQUOTE>

</LI>

</OL>

<P><B>Note (March, 2005):</B></P> 

<P>The 10/2004 resolution interacts with the resolution of <A HREF="
     cwg_defects.html#73">issue 73</A>.  We added wording to 3.9.2 [basic.compound] paragraph 3 to the effect that a pointer containing
the address one past the end of an array is considered to &#8220;point
to&#8221; another object of the same type that might be located there.
The 10/2004 resolution now says that it would be undefined behavior to
use such a pointer to fetch the value of that object.  There is at
least the appearance of conflict here; it may be all right, but it at
needs to be discussed further.</P>

<P><B>Notes from the April, 2005 meeting:</B>
</P>

<P>The CWG agreed that there is no contradiction between this
direction and the resolution of <A HREF="
     cwg_defects.html#73">issue 73</A>.
However, &#8220;not modifiable&#8221; is a compile-time concept, while
in fact this deals with runtime values and thus should produce
undefined behavior instead.  Also, there are other contexts in which
lvalues can occur, such as the left operand of <TT>.</TT>
or <TT>.*</TT>, which should also be restricted.  Additional drafting
is required.</P>

<P>(See also <A HREF="
     cwg_defects.html#1102">issue 1102</A>.)</P>

<BR><BR><HR><A NAME="1653"></A><H4>1653.
  
Removing deprecated increment of <TT>bool</TT>
</H4><B>Section: </B>5.3.2&#160; [expr.pre.incr]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Bjarne Stroustrup
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-19<BR>


<P>The preincrement (5.3.2 [expr.pre.incr]) and postincrement
(5.2.6 [expr.post.incr]) operators can be applied to operands of
type <TT>bool</TT>, setting the operand to <TT>true</TT>, but this
use is deprecated.  Can it now be removed altogether?</P>

<BR><BR><HR><A NAME="901"></A><H4>901.
  
Deleted <TT>operator delete</TT>
</H4><B>Section: </B>5.3.4&#160; [expr.new]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>20 May, 2009<BR>


<P>It is not clear from 5.3.4 [expr.new] whether a deleted
<TT>operator delete</TT> is referenced by a <I>new-expression</I> in
which there is no initialization or in which the initialization cannot
throw an exception, rendering the program ill-formed.  (The question
also arises as to whether such a
<I>new-expression</I> constitutes a &#8220;use&#8221; of the
deallocation function in the sense of 3.2 [basic.def.odr].)</P>

<P><B>Notes from the July, 2009 meeting:</B></P>

<P>The rationale for defining a deallocation function as deleted would
presumably be to prevent such objects from being freed.  Treating the
<I>new-expression</I> as a use of such a deallocation function would
mean that such objects could not be created in the first place.  There
is already an exemption from freeing an object if &#8220;a suitable
deallocation function [cannot] be found;&#8221; a deleted deallocation
function should be treated similarly.</P>

<BR><BR><HR><A NAME="1469"></A><H4>1469.
  
Omitted bound in array <I>new-expression</I>
</H4><B>Section: </B>5.3.4&#160; [expr.new]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2012-02-12<BR>




<P>The syntax for <I>noptr-new-declarator</I> in 5.3.4 [expr.new]
paragraph 1 requires an <I>expression</I>, even though the bound could
be inferred from a <I>braced-init-list</I> initializer.  It is not clear
whether 8.5.1 [dcl.init.aggr] paragraph 4,</P>

<BLOCKQUOTE>

An array of unknown size initialized with a brace-enclosed
<I>initializer-list</I> containing <TT>n</TT>
<I>initializer-clause</I>s, where <TT>n</TT> shall be greater than
zero, is defined as having <TT>n</TT> elements (8.3.4 [dcl.array]).

</BLOCKQUOTE>

<P>should be considered to apply to the <I>new-type-id</I> variant,
e.g.,</P>

<PRE>
  new (int[]){1, 2, 3}
</PRE>

<P><B>Additional note (August, 2012):</B></P>

<P>The consensus during the 2012-08-13 drafting review teleconference
was that this issue should be referred to the Evolution Working Group
and not handled by the Core Working Group.</P>

<BR><BR><HR><A NAME="1786"></A><H4>1786.
  
Effect of merging allocations on memory leakage
</H4><B>Section: </B>5.3.4&#160; [expr.new]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>United Kingdom
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-28<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#GB4">N3690 comment
  GB&#160;4<BR></A>

<P>The strategy of merging allocations could turn a small memory leak
into a big one.  For example,</P>

<PRE>
  class P { 
    int x; 
  }; 
  class Q { 
  public: 
    Q(){ throw 42; } 
  private:
    int x[LARGE_NUMBER]; 
  }; 

  { 
    P* p1 = new P(); 
    Q* q1 = new Q(); //<SPAN style="font-family:Times;font-style:italic"> bang :-( </SPAN>
    //<SPAN style="font-family:Times;font-style:italic"> don't get here </SPAN>
    delete q1; 
    delete p1; 
  } 
</PRE>

<P>Instead of just leaking the first allocation, this could result in
leaking the combined allocation.</P>

<P><B>Notes from the September, 2013 meeting:</B></P>

<P>EWG was not so concerned with memory leaks, but there are problems
with the current wording dealing with lifetime issues.  In particular,
the existing wording did not guarantee that all of the merged allocations
would, in fact, be executed.  The intended direction is to relax the
strict lifetime containment requirement from the current wording but
to ensure that all of the allocations and frees will be executed,
which requires that the allocation and initialization of later objects
be non-throwing.</P>

<BR><BR><HR><A NAME="1598"></A><H4>1598.
  
Criterion for equality of pointers to members
</H4><B>Section: </B>5.10&#160; [expr.eq]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2012-12-21<BR>




<P>According to 5.10 [expr.eq] paragraph 2, pointers to
data members compare equal</P>

<BLOCKQUOTE>

if and only if they would refer to the same member of the same most
derived object (1.8 [intro.object]) or the same subobject if
indirection with a hypothetical object of the associated class type
were performed.

</BLOCKQUOTE>

<P>This specification is overly constrained. For data members, most
implementations simply compare the offsets of the members involved,
violating the &#8220;only if&#8221; part of the specification.  For
example:</P>

<PRE>
  struct A {};
  struct B : A { int x; };
  struct C : A { int x; };

  int A::*bx = (int(A::*))&amp;B::x;
  int A::*cx = (int(A::*))&amp;C::x;

  bool b1 = bx == cx;
</PRE>

<P>The existing wording requires <TT>b1</TT> to have the value
<TT>false</TT>, even though the offsets of the members are the same.
It would be better if the result of the comparison were unspecified
unless the class containing the original member for the LHS is a base
or derived class of the class containing the original member for the
RHS.</P>

<BR><BR><HR><A NAME="1652"></A><H4>1652.
  
Object addresses in <TT>constexpr</TT> expressions
</H4><B>Section: </B>5.10&#160; [expr.eq]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-15<BR>


<P>Pointer equality is defined by reference to the addresses of the
objects designated by the pointer values, reflecting the implementation
technique of most/all compilers.  However, this definition is intrinsically
a runtime property, and such a description is inappropriate with respect to
<TT>constexpr</TT> expressions, which must deal with pointer comparisons
without necessarily knowing the runtime layout of the objects involved.  A
better definition usable at compile time is needed.</P>

<BR><BR><HR><A NAME="1542"></A><H4>1542.
  
Compound assignment of <I>braced-init-list</I>
</H4><B>Section: </B>5.17&#160; [expr.ass]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2012-08-21<BR>


<P>The specification of 5.17 [expr.ass] paragraph 9 is presumably
intended to allow use of a <I>braced-init-list</I> as the operand of a
compound assignment operator as well as a simple assignment operator,
although the normative wording does not explicitly say so.  (The example
in that paragraph does include</P>

<PRE>
  complex&lt;double&gt; z;
  z += { 1, 2 };      //<SPAN style="font-family:Times;font-style:italic"> meaning </SPAN>z.operator+=({1,2})
</PRE>

<P>for instance, which could be read to imply compound assignment
operators for scalar types as well.)</P>

<P>However, the details of how this is to be implemented are not clear.
Paragraph 7 says,</P>

<BLOCKQUOTE>

The behavior of an expression of the form <TT>E1</TT> <I>op</I>
<TT>=</TT> <TT>E2</TT> is equivalent to <TT>E1 = E1</TT> <I>op</I>
<TT>E2</TT> except that <TT>E1</TT> is evaluated only once.

</BLOCKQUOTE>

<P>Applying this pattern literally to a <I>braced-init-list</I> yields
invalid code: <TT>x&#160;+=&#160;{1}</TT> would become
<TT>x&#160;=&#160;x&#160;+&#160;{1}</TT>, which is non-syntactic.</P>

<P>Another problem is how to apply the prohibition against narrowing
conversions to a compound assignment.  For example,</P>

<PRE>
  char c;
  c += {1};
</PRE>

<P>would presumably always be a narrowing error, because after integral
promotions, the type of <TT>c+1</TT> is <TT>int</TT>.  The similar
<A HREF="
     cwg_closed.html#1078">issue 1078</A> was classified as "NAD" because
the workaround was simply to add a cast to suppress the error; however,
there is no place to put a similar cast in a compound assignment.</P>

<P><B>Notes from the October, 2012 meeting:</B></P>

<P>The incorrect description of the meaning of a compound assignment
with a <I>braced-init-list</I> should be fixed by CWG.  The question of
whether it makes sense to apply narrowing rules to such assignments
is better addressed by EWG.</P>

<BR><BR><HR><A NAME="1255"></A><H4>1255.
  
Definition problems with <TT>constexpr</TT> functions
</H4><B>Section: </B>5.19&#160; [expr.const]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-08<BR>




<P>The current wording of the Standard is not sufficiently clear regarding
the interaction of class scope (which treats the bodies of member functions
as effectively appearing after the class definition is complete) and the
use of <TT>constexpr</TT> member functions within the class definition in
contexts requiring constant expressions.  For example, an array bound
cannot use a <TT>constexpr</TT> member function that relies on the
completeness of the class or on members that have not yet been declared,
but the current wording does not appear to state that.</P>

<P><B>Additional note (October, 2013):</B></P>

<P>This question also affects function return type deduction (the
<TT>auto</TT> specifier) in member functions.  For example, the following
should presumably be prohibited, but the current wording is not clear:</P>

<PRE>
  struct S {
    static auto f() {
      return 42;
    }
    auto g() -&gt; decltype(f()) {
      return f();
    }
  };
</PRE>


<BR><BR><HR><A NAME="1452"></A><H4>1452.
  
Value-initialized objects may be constants
</H4><B>Section: </B>5.19&#160; [expr.const]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2011-12-24<BR>




<P>Some classes that would produce a constant when initialized by
value-initialization are not considered literal types.
For example:</P>

<PRE>
   struct A { int a; }; // non-constexpr default constructor
   struct B : A {};     // non-literal type
</PRE>

<BR><BR><HR><A NAME="1480"></A><H4>1480.
  
Constant initialization via non-constant temporary
</H4><B>Section: </B>5.19&#160; [expr.const]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2012-03-17<BR>




<P>The following initializations appear to be well-formed:</P>

<PRE>
  struct C {
   int m;
   constexpr C(int m ) : m{m} {};
   constexpr int get() { return m; };
  };

  C&amp;&amp; rr = C{1};
  constexpr int k1 = rr.get();

  const C&amp; cl = C{1};
  constexpr int k2 = cl.get();
</PRE>

<P>They appear to fall under the bullet of 5.19 [expr.const]
paragraph 2,</P>

<UL><LI>

<P>an lvalue-to-rvalue conversion (4.1 [conv.lval]) unless it is
applied to
</P>
</LI>

<UL>

<LI><P>...</P></LI>

<LI>

<P>a non-volatile glvalue of literal type that refers to a non-volatile
temporary object whose lifetime has not ended, initialized with a
constant expression;
</P>
</LI>

</UL>

</UL>

<P>The problem in this example is that the referenced temporary object
is not a constant, so it would be well-defined for intervening code to
modify its value before it was used in the later initialization.</P>

<P><B>Additional note (February, 2013):</B></P>

<P>The intent is that non-const references to temporaries should be allowed
within constant expressions, e.g., across <TT>constexpr</TT> function
calls, but not as the result of a constant expression.</P>

<BR><BR><HR><A NAME="1626"></A><H4>1626.
  
<TT>constexpr</TT> member functions in <I>brace-or-equal-initializer</I>s
</H4><B>Section: </B>5.19&#160; [expr.const]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2013-02-19<BR>


<P>The Standard should make clear that a <TT>constexpr</TT> member
function cannot be used in a constant expression until its class is
complete.  For example:</P>

<PRE>
  template&lt;typename T&gt; struct C {
    template&lt;typename T2&gt; static constexpr bool _S_chk() {
      return false;
    }
    static const bool __value = _S_chk&lt;int&gt;();
  }; 

  C&lt;double&gt; c;
</PRE>

<P>Current implementations accept this, although they reject the
corresponding non-template case:</P>

<PRE>
  struct C {
    static constexpr bool _S_chk() { return false; }
    static const bool __value = _S_chk();
  };

  C c; 
</PRE>

<P>Presumably the template case should be handled consistently with the
non-template case.</P>

<BR><BR><HR><A NAME="1732"></A><H4>1732.
  
Defining types in <I>condition</I>s and range-based <TT>for</TT> statements
</H4><B>Section: </B>6.4&#160; [stmt.select]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-08-08<BR>




<P>The interaction of various issue resolutions has inadvertently resulted
in the loss of the prohibition of defining types in <I>condition</I>s
(6.4 [stmt.select] paragraph 1) and in a range-based <TT>for</TT>
(6.5 [stmt.iter] paragraph 1).  <A HREF="
     cwg_defects.html#686">Issue 686</A>
addressed a patchwork of restrictions by banning type definitions in
<I>type-specifier-seq</I>s.  <A HREF="
     cwg_defects.html#948">Issue 948</A> then
changed the definition of <I>condition</I> to use a
<I>decl-specifier-seq</I> instead of a <I>type-specifier-seq</I> in order
to permit the <TT>constexpr</TT> specifier.  A similar change was made for
range-based <TT>for</TT> statements by <A HREF="
     cwg_defects.html#1204">issue 1204</A>.</P>

<P>The restrictions against type definitions in these contexts should be
restored.</P>

<BR><BR><HR><A NAME="1274"></A><H4>1274.
  
Common nonterminal for <I>expression</I> and <I>braced-init-list</I>
</H4><B>Section: </B>6.5.4&#160; [stmt.ranged]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-25<BR>




<P>It would be helpful to have a single grammar term for
<I>expression</I> and <I>braced-init-list</I>, which often occur
together in the text.  In particular, 6.5.4 [stmt.ranged]
paragraph 1 allows both, but the description of <TT>__RangeT</TT>
refers only to the <I>expression</I> case; such errors would be less
likely if the common term were available.</P>

<BR><BR><HR><A NAME="1523"></A><H4>1523.
  
Point of declaration in range-based <TT>for</TT>
</H4><B>Section: </B>6.5.4&#160; [stmt.ranged]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2012-07-16<BR>


<P>According to the general rule for declarations in 3.3.2 [basic.scope.pdecl]
paragraph 1,</P>

<BLOCKQUOTE>

The <I>point of declaration</I> for a name is immediately after its
complete declarator (Clause 8 [dcl.decl]) and before its
<I>initializer</I> (if any), except as noted below.

</BLOCKQUOTE>

<P>However, the rewritten expansion of the range-based <TT>for</TT>
statement in 6.5.4 [stmt.ranged] paragraph 1 contradicts
this general rule, so that the index variable is not visible in the
<I>range-init</I>:</P>

<PRE>
  for (int i : {i}) ;   //<SPAN style="font-family:Times;font-style:italic"> error: </SPAN>i<SPAN style="font-family:Times;font-style:italic"> not in scope</SPAN>
</PRE>

<P>(See also <A HREF="
     cwg_closed.html#1498">issue 1498</A> for another
question regarding the rewritten form of the range-based <TT>for</TT>.)</P>

<P><B>Notes from the October, 2012 meeting:</B></P>

<P>EWG is discussing <A HREF="
     cwg_closed.html#900">issue 900</A> and the
outcome of that discussion should be taken into consideration in
addressing this issue.</P>

<P><B>Notes from the April, 2013 meeting:</B></P>

<P>The approach favored by CWG for resolving this issue is to change
the point of declaration of the variable in the <I>for-range-declaration</I>
to be after the <TT>)</TT>.</P>

<BR><BR><HR><A NAME="1680"></A><H4>1680.
  
Including <TT>&lt;initializer_list&gt;</TT> for range-based <TT>for</TT>
</H4><B>Section: </B>6.5.4&#160; [stmt.ranged]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-05-13<BR>




<P>A simple example like</P>

<PRE>
  int main() {
    int k = 0;
    for (auto x : { 1, 2, 3 })
      k += x;
    return k;
  }
</PRE>

<P>requires that the <TT>&lt;initializer_list&gt;</TT> header be
included, because the expansion of the range-based <TT>for</TT> involves
a declaration of the form</P>

<PRE>
  auto &amp;&amp;__range = { 1, 2, 3 };
</PRE>

<P>and a <I>braced-init-list</I> causes <TT>auto</TT> to be deduced
as a specialization of <TT>std::initializer_list</TT>.  This seems
unnecessary and could be eliminated by specifying that <TT>__range</TT>
has an array type for cases like this.</P>

<P>(It should be noted that EWG is considering a proposal to change
<TT>auto</TT> deduction for cases involving <I>braced-init-list</I>s,
so resolution of this issue should be coordinated with that effort.)</P>

<P><B>Notes from the September, 2013 meeting:</B></P>

<P>CWG felt that this issue should be resolved by using the array
variant of the range-based <TT>for</TT> implementation.</P>

<BR><BR><HR><A NAME="1223"></A><H4>1223.
  
Syntactic disambiguation and <I>trailing-return-type</I>s
</H4><B>Section: </B>6.8&#160; [stmt.ambig]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2010-11-08<BR>


<P>Because the restriction that a <I>trailing-return-type</I> can
appear only in a declaration with &#8220;the single <I>type-specifier</I>
<TT>auto</TT>&#8221; (8.3.5 [dcl.fct] paragraph 2) is a
semantic, not a syntactic, restriction, it does not influence
disambiguation, which is &#8220;purely syntactic&#8221;
(6.8 [stmt.ambig] paragraph 3).  Consequently, some
previously unambiguous expressions are now ambiguous.  For example:</P>

<PRE>
struct A {
  A(int *);
  A *operator()(void);
  int B;
};
 
int *p;
typedef struct BB { int C[2]; } *B, C;
 
void foo() {
// The following line becomes invalid under C++0x:
  A (p)()-&gt;B;  // ill-formed function declaration
 
// In the following,
// - B()-&gt;C is either type-id or class member access expression
// - B()-&gt;C[1] is either type-id or subscripting expression
// N3126 subclause 8.2 [dcl.ambig.res] does not mention an ambiguity
// with these forms of expression
  A a(B ()-&gt;C);  // function declaration or object declaration
  sizeof(B ()-&gt;C[1]);  // sizeof(type-id) or sizeof on an expression
}
</PRE>

<P><B>Notes from the March, 2011 meeting:</B></P>

<P>CWG agreed that the presence of <TT>auto</TT> should be considered
in disambiguation, even though it is formally handled semantically
rather than syntactically.</P>

<BR><BR><HR><A NAME="1616"></A><H4>1616.
  
Disambiguation parsing and template parameters
</H4><B>Section: </B>6.8&#160; [stmt.ambig]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2013-02-01<BR>




<P>According to 6.8 [stmt.ambig] paragraph 3,</P>

<BLOCKQUOTE>

The disambiguation is purely syntactic; that is, the meaning of the names
occurring in such a statement, beyond whether they are <I>type-name</I>s or
not, is not generally used in or changed by the disambiguation. Class
templates are instantiated as necessary to determine if a qualified name is
a <I>type-name</I>. Disambiguation precedes parsing, and a statement
disambiguated as a declaration may be an ill-formed declaration. If, during
parsing, a name in a template parameter is bound differently than it would
be bound during a trial parse, the program is ill-formed. No diagnostic is
required. [<I>Note:</I> This can occur only when the name is declared
earlier in the declaration. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>The statement about template parameters is confusing (and not helped by
the fact that the example that follows illustrates the general rule for
declarations and does not involve any template parameters).  It is
attempting to say that a program is ill-formed if a template argument of a
class template specialization has a different value in the two parses.
With <TT>decltype</TT> this can now apply to other kinds of templates as
well, so the wording should be clarified and made more general.</P>

<BR><BR><HR><A NAME="1325"></A><H4>1325.
  
Omitted declarator in <TT>friend</TT> declarations
</H4><B>Section: </B>7&#160; [dcl.dcl]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2011-05-27<BR>




<P>According to 7 [dcl.dcl] paragraph 3,</P>

<BLOCKQUOTE>

In a <I>simple-declaration</I>, the optional
<I>init-declarator-list</I> can be omitted only when declaring a class
(Clause 9 [class]) or enumeration (7.2 [dcl.enum]), that is, when the <I>decl-specifier-seq</I> contains
either a <I>class-specifier</I>, an <I>elaborated-type-specifier</I>
with a <I>class-key</I> (9.1 [class.name]), or an
<I>enum-specifier</I>.

</BLOCKQUOTE>

<P>This does not allow for the new simplified <TT>friend</TT>
declaration syntax (11.3 [class.friend] paragraph 3), which
permits the forms</P>

<UL><TT>friend</TT> <I>simple-type-specifier</I> <TT>;</TT><BR>
<TT>friend</TT> <I>typename-specifier</I> <TT>;</TT>
</UL>

<BR><BR><HR><A NAME="1247"></A><H4>1247.
  
Restriction on alias name appearing in <I>type-id</I>
</H4><B>Section: </B>7.1.3&#160; [dcl.typedef]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>2011-02-26<BR>




<P>With the resolution of <A HREF="
     cwg_defects.html#1044">issue 1044</A>,
there is no need to say that the name of the alias cannot appear in
the <I>type-id</I> of the declaration.</P>

<BR><BR><HR><A NAME="1684"></A><H4>1684.
  
Static <TT>constexpr</TT> member functions for non-literal classes
</H4><B>Section: </B>7.1.5&#160; [dcl.constexpr]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-05-15<BR>


<P>The current wording of 7.1.5 [dcl.constexpr] paragraph 8 is:</P>

<BLOCKQUOTE>

The <TT>constexpr</TT> specifier has no effect on the type of
a <TT>constexpr</TT> function or a <TT>constexpr</TT> constructor. The
class of which a <TT>constexpr</TT> function is a member shall be a literal
type (3.9 [basic.types]).

</BLOCKQUOTE>

<P>The previous version of this wording made clear that the restriction
on the class type applied only to non-static member functions;
consequently, the new formulation has inadvertently banned static
<TT>constexpr</TT> member functions of non-literal classes.</P>

<BR><BR><HR><A NAME="1712"></A><H4>1712.
  
<TT>constexpr</TT> variable template declarations
</H4><B>Section: </B>7.1.5&#160; [dcl.constexpr]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-07-08<BR>




<P>According to 7.1.5 [dcl.constexpr] paragraph 1,</P>

<BLOCKQUOTE>

If any declaration of a function, function template, or variable template
has a <TT>constexpr</TT> specifier, then all its declarations shall contain
the <TT>constexpr</TT> specifier.

</BLOCKQUOTE>

<P>This requirement does not make sense applied to variable templates.
The <TT>constexpr</TT> specifier requires that there be an initializer,
and a variable template declaration with an initializer is a definition,
so there cannot be more than one declaration of a variable template
with the <TT>constexpr</TT> specifier.</P>

<BR><BR><HR><A NAME="1707"></A><H4>1707.
  
<TT>template</TT> in <I>elaborated-type-specifier</I> without <I>nested-name-specifier</I>
</H4><B>Section: </B>7.1.6.3&#160; [dcl.type.elab]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-06-27<BR>




<P>The grammar for <I>elaborated-type-specifier</I> in
7.1.6.3 [dcl.type.elab] reads, in part,</P>

<UL><I>elaborated-type-specifier:</I>
<UL><I>class-key nested-name-specifier<SUB>opt</SUB></I> <TT>template</TT><I><SUB>opt</SUB> simple-template-id</I>

</UL>

</UL>

<P>This allows use of the <TT>template</TT> keyword without a
<I>nested-name-specifier</I>, e.g., <TT>struct template S&lt;int&gt;</TT>.
This is inconsistent with other uses of the <TT>template</TT> keyword.
It might be better to split the production in two and only allow the
keyword following a <I>nested-name-specifier</I>, i.e.,</P>

<UL><I>elaborated-type-specifier:</I>
<UL><I>class-key simple-template-id</I><BR>
<I>class-key nested-name-specifier</I> <TT>template</TT><I><SUB>opt</SUB> simple-template-id</I>

</UL>

</UL>

<BR><BR><HR><A NAME="1348"></A><H4>1348.
  
Use of <TT>auto</TT> in a <I>trailing-return-type</I>
</H4><B>Section: </B>7.1.6.4&#160; [dcl.spec.auto]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2011-08-16<BR>




<P>It is not clear whether the <TT>auto</TT> specifier can appear
in a <I>trailing-return-type</I>.</P>

<BR><BR><HR><A NAME="1674"></A><H4>1674.
  
Return type deduction for address of function
</H4><B>Section: </B>7.1.6.4&#160; [dcl.spec.auto]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-05-02<BR>




<P>The following example appears in 7.1.6.4 [dcl.spec.auto] paragraph
12:</P>

<PRE>
  template &lt;class T&gt; auto f(T t) { return t; } //<SPAN style="font-family:Times;font-style:italic"> return type deduced at instantiation time</SPAN>
  typedef decltype(f(1)) fint_t;               //<SPAN style="font-family:Times;font-style:italic"> instantiates </SPAN>f&lt;int&gt;<SPAN style="font-family:Times;font-style:italic"> to deduce return type</SPAN>
  template&lt;class T&gt; auto f(T* t) { return *t; }
  void g() { int (*p)(int*) = &amp;f; }            //<SPAN style="font-family:Times;font-style:italic"> instantiates both </SPAN>f<SPAN style="font-family:Times;font-style:italic">s to determine return types,</SPAN>
                                               //<SPAN style="font-family:Times;font-style:italic"> chooses second</SPAN>
</PRE>

<P>This is the desired behavior, but the current wording does not achieve
that effect.  One possible way this could work would be:</P>

<UL><LI><P><TT>auto</TT> is treated as a non-deduced context</P></LI>

<LI>

<P>in 14.8.2.2 [temp.deduct.funcaddr], the deduced <TT>A</TT> is produced by
substituting the deduced template arguments into the original function
template, rather than substituting them into <TT>P</TT>, and the
deduced <TT>A</TT> is the type of the produced function declaration
(triggering instantiation of a definition as needed to complete the
type)</P></LI>

</UL>

<BR><BR><HR><A NAME="1485"></A><H4>1485.
  
Out-of-class definition of member unscoped opaque enumeration
</H4><B>Section: </B>7.2&#160; [dcl.enum]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2012-03-26<BR>




<P>The scope in which the names of enumerators are entered for
a member unscoped opaque enumeration is not clear.  According to
7.2 [dcl.enum] paragraph 10,</P>

<BLOCKQUOTE>

Each <I>enum-name</I> and each unscoped enumerator is declared in the
scope that immediately contains the <I>enum-specifier</I>.

</BLOCKQUOTE>

<P>In the case of a member opaque enumeration defined outside its
containing class, however, it is not clear whether the enumerator
names are declared in the class scope or in the lexical scope
containing the definition. Declaring them in the class scope would
be a violation of 9.2 [class.mem] paragraph 1:</P>

<BLOCKQUOTE>

The <I>member-specification</I> in a class definition declares the
full set of members of the class; no member can be added elsewhere.

</BLOCKQUOTE>

<P>Declaring the names in the lexical scope containing the
definition would be contrary to the example in
14.5.1.4 [temp.mem.enum] paragraph 1:</P>

<PRE>
  template&lt;class T&gt; struct A {
    enum E : T;
  };
  A&lt;int&gt; a;
  template&lt;class T&gt; enum A&lt;T&gt;::E : T { e1, e2 };
  A&lt;int&gt;::E e = A&lt;int&gt;::e1;
</PRE>

<P>There also appear to be problems with the rules for dependent
types and members of the current instantiation.</P>

<BR><BR><HR><A NAME="1636"></A><H4>1636.
  
Bits required for negative enumerator values
</H4><B>Section: </B>7.2&#160; [dcl.enum]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Hyman Rosen
 &#160;&#160;&#160;

 <B>Date: </B>2013-03-07<BR>


<P>According to 7.2 [dcl.enum] paragraph 7,</P>

<BLOCKQUOTE>

For an enumeration whose underlying type is fixed, the values of the
enumeration are the values of the underlying type.  Otherwise,
for an enumeration where <I>e<SUB>min</SUB></I> is the smallest
enumerator and <I>e<SUB>max</SUB></I> is the largest, the values of
the enumeration are the values in the range <I>b<SUB>min</SUB></I> to
<I>b<SUB>max</SUB></I>, defined as follows: Let <I>K</I> be 1 for a
two's complement representation and 0 for a one's complement or
sign-magnitude representation.  <I>b<SUB>max</SUB></I> is the smallest
value greater than or equal to
max(|<I>e<SUB>min</SUB></I>|-<I>K</I>,|<I>e<SUB>max</SUB></I>|) and
equal to 2<I><SUP>M</SUP></I>-1, where <I>M</I> is a non-negative
integer.  <I>b<SUB>min</SUB></I> is zero if <I>e<SUB>min</SUB></I> is
non-negative and -(<I>b<SUB>max</SUB></I>+<I>K</I>) otherwise.  The
size of the smallest bit-field large enough to hold all the values of
the enumeration type is max(<I>M</I>,1) if <I>b<SUB>min</SUB></I> is
zero and <I>M</I>+1 otherwise.

</BLOCKQUOTE>

<P>The result of these calculations is that the number of bits
required for</P>

<PRE>
  enum { N = -1, Z = 0 }
</PRE>

<P>is 1, but the number required for</P>

<PRE>
  enum { N = -1 }
</PRE>

<P>is 2.  This is surprising.  This could be fixed by changing
|<I>e<SUB>max</SUB></I>| to <I>e<SUB>max</SUB></I>.</P>

<BR><BR><HR><A NAME="1638"></A><H4>1638.
  
Declaring an explicit specialization of a scoped enumeration
</H4><B>Section: </B>7.2&#160; [dcl.enum]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-03-12<BR>




<P>There is no syntax currently for declaring an explicit specialization of
a member scoped enumeration.  A declaration (not a definition) of such an
explicit specialization most resembles an <I>opaque-enum-declaration</I>,
but the grammar for that requires that the name be a simple identifier,
which will not be the case for an explicit specialization of a member
enumeration.  This could be remedied by adding
a <I>nested-name-specifier</I> to the grammar with a restriction that
a <I>nested-name-specifier</I> only appear in an explicit
specialization.</P>

<BR><BR><HR><A NAME="138"></A><H4>138.
  
Friend declaration name lookup
</H4><B>Section: </B>7.3.1.2&#160; [namespace.memdef]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Martin von Loewis
 &#160;&#160;&#160;

 <B>Date: </B>14 Jul 1999<BR>





<P>7.3.1.2 [namespace.memdef]
 paragraph 3 says,</P>

<BLOCKQUOTE>
If a <TT>friend</TT> declaration in a non-local class first declares a
class or function the friend class or function is a member of the
innermost enclosing namespace...  When looking for a prior declaration
of a class or a function declared as a <TT>friend</TT>, scopes outside
the innermost enclosing namespace scope are not considered.
</BLOCKQUOTE>

It is not clear from this passage how to determine whether an entity
is "first declared" in a <TT>friend</TT> declaration.  One question is
whether a <I>using-declaration</I> influences this determination.
For instance:

<PRE>
    void foo();
    namespace A{
      using ::foo;
      class X{
	friend void foo();
      };
    }
</PRE>

Is the <TT>friend</TT> declaration a reference to <TT>::foo</TT> or
a different <TT>foo</TT>?

<P>Part of the question involves determining the meaning of
the word "synonym" in
7.3.3 [namespace.udecl]
 paragraph 1:</P>

<BLOCKQUOTE>
A <I>using-declaration</I> introduces a name into the declarative
region in which the <I>using-declaration</I> appears.  That name
is a synonym for the name of some entity declared elsewhere.
</BLOCKQUOTE>

Is "<TT>using ::foo;</TT>" the declaration of a function or not?

<P>More generally, the question is how to describe the lookup of the
name in a <TT>friend</TT> declaration.</P>

<P><U>John Spicer</U>:
When a declaration specifies an unqualified name, that
name is declared, not looked up.  There is a mechanism in which that
declaration is linked to a prior declaration, but that mechanism is
not, in my opinion, via normal name lookup.  So, the friend always
declares a member of the nearest namespace scope regardless of how
that name may or may not already be declared there.</P>

<P><U>Mike Miller</U>:
3.4.1 [basic.lookup.unqual]
 paragraph 7 says:</P>

<BLOCKQUOTE>
A name used in the definition of a class <TT>X</TT> outside of a
member function body or nested class definition shall be declared in
one of the following ways:...  [<I>Note:</I> when looking for a
prior declaration of a class or function introduced by a <TT>friend</TT>
declaration, scopes outside of the innermost enclosing namespace scope
are not considered.]
</BLOCKQUOTE>

The presence of this note certainly implies that this paragraph
describes the lookup of names in <TT>friend</TT> declarations.

<P><U>John Spicer</U>:
It most certainly does not.  If that section described the friend
lookup it would yield the incorrect results for the friend declarations
of <TT>f</TT> and <TT>g</TT> below.
I don't know why that note is there, but it can't
be taken to mean that that is how the friend lookup is done.</P>

<PRE>
    void f(){}
    void g(){}
    class B {
        void g();
    };
    class A : public B {
        void f();
        friend void f(); // ::f not A::f
        friend void g(); // ::g not B::g
    };
</PRE>

<P><U>Mike Miller</U>:
If so, the lookups for friend functions and classes behave differently.
Consider the example in
3.4.4 [basic.lookup.elab]
 paragraph 3:</P>

<PRE>
    struct Base {
        struct Data;         // <I>OK: declares nested</I> Data
        friend class Data;   // <I>OK: nested</I> Data <I>is a friend</I>
    };
</PRE>

<P>If the <TT>friend</TT> declaration is <I>not</I> a reference to
<TT>::foo</TT>, there is a related but separate question: does the
<TT>friend</TT> declaration introduce a conflicting (albeit "invisible")
declaration into namespace <TT>A</TT>, or is it simply a reference
to an as-yet undeclared (and, in this instance, undeclarable)
<TT>A::foo</TT>?  Another part of the example in
3.4.4 [basic.lookup.elab]
 paragraph 3 is
related:</P>

<PRE>
    struct Data {
        friend struct Glob;  // <I>OK: Refers to (as yet) undeclared</I> Glob
                             // <I>at global scope.</I>
    };
</PRE>

<P><U>John Spicer</U>:
You can't refer to something that has not yet been declared.  The friend
is a declaration of <TT>Glob</TT>,
it just happens to declare it in a such a way that
its name cannot be used until it is redeclared.</P>

<P>(A somewhat similar question has been raised in connection with
<A HREF="
     cwg_active.html#36">issue 36</A>.  Consider:</P>

<PRE>
    namespace N {
        struct S { };
    }
    using N::S;
    struct S;          // legal?
</PRE>

<P>According to 9.1 [class.name] paragraph 2,</P>

<BLOCKQUOTE>

A declaration consisting solely of <I>class-key identifier ;</I>
is either a redeclaration of the name in the current scope or a
forward declaration of the identifier as a class name.

</BLOCKQUOTE>

<P>Should the elaborated type declaration in this example be
considered a redeclaration of <TT>N::S</TT> or an invalid
forward declaration of a different class?)</P>

<P>(See also issues
<A HREF="
     cwg_closed.html#95">95</A>,
<A HREF="
     cwg_defects.html#136">136</A>,
<A HREF="
     cwg_defects.html#139">139</A>,
<A HREF="
     cwg_defects.html#143">143</A>,
<A HREF="
     cwg_closed.html#165">165</A>, and
<A HREF="
     cwg_defects.html#166">166</A>, as well as paper J16/00-0006 = WG21
N1229.)</P>





<BR><BR><HR><A NAME="386"></A><H4>386.
  
Friend declaration of name brought in by <I>using-declaration</I>
</H4><B>Section: </B>7.3.3&#160; [namespace.udecl]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Herb Sutter
 &#160;&#160;&#160;

 <B>Date: </B>8 Oct 2002<BR>


<P>The following came up recently on comp.lang.c++.moderated (edited for
brevity):</P>
<PRE>
  namespace N1 {
    template&lt;typename T&gt; void f( T* x ) {
      // ... other stuff ...
      delete x;
    }
  }

  namespace N2 {
    using N1::f;

    template&lt;&gt; void f&lt;int&gt;( int* ); // A: ill-formed

    class Test {
      ~Test() { }
      friend void f&lt;&gt;( Test* x );   // B: ill-formed?
    };
  }
</PRE>
<P>I strongly suspect, but don't have standardese to prove, that the friend
declaration in line B is ill-formed. Can someone show me the text that
allows or disallows line B?</P>

<P>Here's my reasoning: Writing "using" to pull the name into namespace N2
merely allows code in N2 to use the name in a call without qualification
(per 7.3.3 [namespace.udecl]).
But just as declaring a specialization must be done in the
namespace where the template really lives (hence line A is ill-formed), I
suspect that declaring a specialization as a friend must likewise be done
using the original namespace name, not obliquely through a "using". I see
nothing in 7.3.3 [namespace.udecl]
that would permit this use. Is there?</P>

<P><U>Andrey Tarasevich</U>:
14.5.4 [temp.friend] paragraph 2 seems to get pretty close:
"A friend declaration that is not a
template declaration and in which the name of the friend is an unqualified
'template-id' shall refer to a specialization of a function template
declared in the nearest enclosing namespace scope". </P>

<P><U>Herb Sutter</U>:
OK, thanks. Then the question in this is the word "declared" -- in
particular, we already know we cannot declare a specialization of a template
in any other namespace but the original one.</P>

<P><U>John Spicer</U>:
This seems like a simple question, but it isn't.</P>

<P>First of all, I don't think the standard comments on this usage one way 
or the other.</P>

<P>A similar example using a namespace qualified name is ill-formed based 
on 8.3 [dcl.meaning] paragraph 1:</P>
<PRE>
  namespace N1 {
        void f();
  }

  namespace N2 {
        using N1::f;
        class A {
                friend void N2::f();
        };
  }
</PRE>

<P><A HREF="
     cwg_active.html#138">Core issue 138</A> deals with this example:</P>
<PRE>
  void foo();
  namespace A{
    using ::foo;
    class X{
      friend void foo();
    };
  }
</PRE>
<P>The proposed resolution (not yet approved) for
<A HREF="
     cwg_active.html#138">issue 138</A> is that the 
friend declares a new
foo that conflicts with the using-declaration and results in an error.</P>

<P>Your example is different than this though because the presence of the 
explicit argument list
means that this is not declaring a new f but is instead using a 
previously declared f.</P>

<P>One reservation I have about allowing the example is the desire to have 
consistent rules for all of the "declaration like" uses of template 
functions.   <A HREF="
     cwg_defects.html#275">Issue 275</A> (in DR status) addresses the
issue of unqualified names in explicit instantiation and explicit 
specialization declarations.
It requires that such declarations refer to templates from the namespace 
containing the
explicit instantiation or explicit specialization.  I believe this rule 
is necessary for those directives but is not really required for friend 
declarations -- but there is the consistency issue.</P>

<P><B>Notes from April 2003 meeting:</B></P>

<P>This is related to <A HREF="
     cwg_active.html#138">issue 138</A>.  John Spicer
is supposed to update his paper on this topic.  This is a new case
not covered in that paper.  We agreed that the B line should be
allowed.</P>

<BR><BR><HR><A NAME="1708"></A><H4>1708.
  
overly-strict requirements for names with C language linkage
</H4><B>Section: </B>7.5&#160; [dcl.link]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-06-29<BR>




<P>According to 7.5 [dcl.link] paragraph 6,</P>

<BLOCKQUOTE>

An entity with C language linkage shall not be declared with the same name
as an entity in global scope, unless both declarations denote the same
entity; no diagnostic is required if the declarations appear in different
translation units.

</BLOCKQUOTE>

<P>This restriction is too broad; it does not allow for the so-called
<TT>stat</TT> hack, where a C-linkage function and a class are both
declared in global scope, and it does not allow for function overloading,
either.  It should be revised to apply only to variables.</P>

<BR><BR><HR><A NAME="1689"></A><H4>1689.
  
Syntactic nonterminal for operand of <TT>alignas</TT>
</H4><B>Section: </B>7.6.1&#160; [dcl.attr.grammar]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-05-26<BR>


<P><A HREF="
     cwg_closed.html#1323">Issue 1323</A> dealt with correcting the
specification of the operand of <TT>alignas</TT>, which was originally
given as the nonexistent term <I>alignment-expression</I>.  It was
corrected editorially to match the use of <I>assignment-expression</I>
in 7.6.2 [dcl.align]</P>

<P>In 7.6.2 [dcl.align] paragraph 2, the expression is
semantically constrained to be an integral constant expression.  Since
a <I>constant-expression</I> is syntactically
a <I>conditional-expression</I> rather than
an <I>assignment-expression</I>, it would probably make sense to change the
syntactic nonterminal for the operand of <TT>alignas</TT> to be either
a <I>constant-expression</I> or a <I>conditional-expression</I>.</P>

<BR><BR><HR><A NAME="1342"></A><H4>1342.
  
Order of initialization with multiple declarators
</H4><B>Section: </B>8&#160; [dcl.decl]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Alberto Ganesh Barbati
 &#160;&#160;&#160;

 <B>Date: </B>2011-08-11<BR>




<P>It is not clear what, if anything, in the existing specification
requires that the initialization of multiple <I>init-declarator</I>s
within a single declaration be performed in declaration order.</P>

<BR><BR><HR><A NAME="1488"></A><H4>1488.
  
<I>abstract-pack-declarator</I>s in <I>type-id</I>s
</H4><B>Section: </B>8.1&#160; [dcl.name]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2012-03-28<BR>




<P>The grammar for <I>type-id</I> in 9.1 [class.name] paragraph
1 has two problems.  First, the fact that we allow an
<I>abstract-pack-declarator</I> makes some uses of <I>type-id</I>
(template arguments, alignment specifiers, exception-specifications)
ambiguous: <TT>T...</TT> could be parsed either as a <I>type-id</I>,
including the ellipsis, or as the <I>type-id</I> <TT>T</TT> with a
following ellipsis.  There does not appear to be any rule to
disambiguate these parses.</P>

<P>The other problem is that we do not allow parentheses in an
<I>abstract-pack-declarator</I>, which makes</P>

<PRE>
  template&lt;typename...Ts&gt; void f(Ts (&amp;...)[4]);
</PRE>

<P>ill-formed because <TT>(&amp;...)()</TT> is not an
<I>abstract-pack-declarator</I>.  There is implementation variance
on this point.</P>

<BR><BR><HR><A NAME="453"></A><H4>453.
  
References may only bind to &#8220;valid&#8221; objects
</H4><B>Section: </B>8.3.2&#160; [dcl.ref]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Gennaro Prota
 &#160;&#160;&#160;

 <B>Date: </B>18 Jan 2004<BR>


<P>8.3.2 [dcl.ref] paragraph 4 says:</P>
<BLOCKQUOTE>
  A reference shall be initialized to refer to a valid object or
  function. [Note: in particular, a null reference cannot exist
  in a well-defined program, because the only way to create such
  a reference would be to bind it to the "object" obtained by
  dereferencing a null pointer, which causes undefined behavior
  ...]
</BLOCKQUOTE>
<P>What is a "valid" object? In particular the expression "valid object"
seems to exclude uninitialized objects, but the response to Core Issue
363 clearly says that's not the intent. This is an example
(overloading construction on constness of *this) by John Potter, which
I think is supposed to be legal C++ though it binds references to
objects that are not initialized yet:</P>
<PRE>
 struct Fun {
    int x, y;
    Fun (int x, Fun const&amp;) : x(x), y(42) { }
    Fun (int x, Fun&amp;) : x(x), y(0) { }
  };
  int main () {
    const Fun f1 (13, f1);
    Fun f2 (13, f2);
    cout &lt;&lt; f1.y &lt;&lt; " " &lt;&lt; f2.y &lt;&lt; "\n";
  }
</PRE>

<P>Suggested resolution: Changing the final part of
8.3.2 [dcl.ref] paragraph 4 to:</P>
<BLOCKQUOTE>
  A reference shall be initialized to refer to an object or function.
  From its point of declaration on (see 3.3.2 [basic.scope.pdecl])
  its name is an lvalue
  which refers to that object or function. The reference may be
  initialized to refer to an uninitialized object but, in that case,
  it is usable in limited ways (3.8 [basic.life], paragraph 6)
  [Note: On the other hand, a declaration like this:
<PRE>
    int &amp; ref = *(int*)0;
</PRE>
  is ill-formed because ref will not refer to any object or function
  ]
</BLOCKQUOTE>

<P>I also think a "No diagnostic is required." would better be added
(what about something like int&amp; r = r; ?)</P>

<P><B>Proposed Resolution (October, 2004):</B></P>

<P>(Note: the following wording depends on the proposed
resolution for <A HREF="
     cwg_active.html#232">issue 232</A>.)</P>

<P>Change 8.3.2 [dcl.ref] paragraph 4 as follows:</P>
<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">A reference shall be initialized to refer to a valid object
or function.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">If an lvalue to which a reference is directly
bound designates neither an existing object or function of an
appropriate type (8.5.3 [dcl.init.ref]), nor a region of
memory of suitable size and alignment to contain an object of the
reference's type (1.8 [intro.object], 3.8 [basic.life], 3.9 [basic.types]), the behavior is
undefined.</SPAN> [<I>Note:</I> in particular, a null reference cannot
exist in a well-defined program, because the only way to create
such a reference would be to bind it to the
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">&#8220;object&#8221;</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">empty lvalue</SPAN> obtained by
dereferencing a null pointer, which <SPAN style="text-decoration:line-through;background-color:#FFA0A0">causes undefined behavior.
As</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">does not designate an object or function.  Also, as
</SPAN> described in 9.6 [class.bit],
a reference cannot be bound directly to a
bit-field. ]</P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">The name of a reference shall not be used in its own
initializer.  Any other use of a reference before it is
initialized results in undefined behavior.  [<I>Example:</I>
</SPAN></P>

<SPAN style="font-weight:bold;background-color:#A0FFA0">
<PRE>
  int&amp; f(int&amp;);
  int&amp; g();

  extern int&amp; ir3;
  int* ip = 0;

  int&amp; ir1 = *ip;     // <I>undefined behavior: null pointer</I>
  int&amp; ir2 = f(ir3);  // <I>undefined behavior: </I>ir3<I> not yet initialized</I>
  int&amp; ir3 = g();
  int&amp; ir4 = f(ir4);  // <I>ill-formed: </I>ir4<I> used in its own initializer</I>
</PRE>
&#8212;<I>end example</I>]
</SPAN>
</BLOCKQUOTE>

<P><B>Rationale: </B> The proposed wording goes beyond the specific
concerns of the issue.  It was noted that, while the current
wording makes cases like <TT>int&amp; r = r;</TT> ill-formed (because
<TT>r</TT> in the initializer does not "refer to a valid object"), an
inappropriate initialization can only be detected, if at all, at
runtime and thus "undefined behavior" is a more appropriate treatment.
Nevertheless, it was deemed desirable to continue to require a
diagnostic for obvious compile-time cases.
</P>

<P>It was also noted that the current Standard does not say anything
about using a reference before it is initialized.  It seemed
reasonable to address both of these concerns in the same wording
proposed to resolve this issue.
</P>

<P><B>Notes from the April, 2005 meeting:</B></P>

<P>The CWG decided that whether to require an implementation to
diagnose initialization of a reference to itself should be handled as
a separate issue (<A HREF="
     cwg_active.html#504">504</A>) and also suggested referring
to &#8220;storage&#8221; instead of &#8220;memory&#8221; (because
1.8 [intro.object] defines an object as a &#8220;region of
storage&#8221;).</P>

<P><B>Proposed Resolution (April, 2005):</B></P>

<P>(Note: the following wording depends on the proposed
resolution for <A HREF="
     cwg_active.html#232">issue 232</A>.)</P>

<P>Change 8.3.2 [dcl.ref] paragraph 4 as follows:</P>
<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">A reference shall be initialized to refer to a valid object
or function.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">If an lvalue to which a reference is directly
bound designates neither an existing object or function of an
appropriate type (8.5.3 [dcl.init.ref]), nor a region of
storage of suitable size and alignment to contain an object of the
reference's type (1.8 [intro.object], 3.8 [basic.life], 3.9 [basic.types]), the behavior is
undefined.</SPAN> [<I>Note:</I> in particular, a null reference cannot
exist in a well-defined program, because the only way to create
such a reference would be to bind it to the
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">&#8220;object&#8221;</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">empty lvalue</SPAN> obtained by
dereferencing a null pointer, which <SPAN style="text-decoration:line-through;background-color:#FFA0A0">causes undefined behavior.
As</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">does not designate an object or function.  Also, as
</SPAN> described in 9.6 [class.bit],
a reference cannot be bound directly to a
bit-field. ]</P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">Any use of a reference before it is initialized results in
undefined behavior.  [<I>Example:</I>
</SPAN></P>

<SPAN style="font-weight:bold;background-color:#A0FFA0">
<PRE>
  int&amp; f(int&amp;);
  int&amp; g();

  extern int&amp; ir3;
  int* ip = 0;

  int&amp; ir1 = *ip;     // <SPAN style="font-family:Times;font-style:italic">undefined behavior: null pointer</SPAN>
  int&amp; ir2 = f(ir3);  // <SPAN style="font-family:Times;font-style:italic">undefined behavior: </SPAN>ir3<SPAN style="font-family:Times;font-style:italic"> not yet initialized</SPAN>
  int&amp; ir3 = g();
  int&amp; ir4 = f(ir4);  // <SPAN style="font-family:Times;font-style:italic">undefined behavior: </SPAN>ir4<SPAN style="font-family:Times;font-style:italic"> used in its own initializer</SPAN>
</PRE>
&#8212;<I>end example</I>]
</SPAN>
</BLOCKQUOTE>

<P><B>Note (February, 2006):</B></P>

<P>The word &#8220;use&#8221; in the last
paragraph of the proposed resolution was intended to refer to the
description in 3.2 [basic.def.odr] paragraph 2.  However, that
section does not define what it means for a reference to be
&#8220;used,&#8221; dealing only with objects and functions.  Additional
drafting is required to extend 3.2 [basic.def.odr] paragraph 2
to apply to references.  </P>

<P><B>Additional note (May, 2008):</B></P>

<P>The proposed resolution for <A HREF="
     cwg_defects.html#570">issue 570</A>
adds wording to define &#8220;use&#8221; for references.</P>

<P><B>Note, January, 2012:</B></P>

<P>The resolution should also probably deal with the fact that
the &#8220;one-past-the-end&#8221; address of an array does not
designate a valid object (even if such a pointer might
&#8220;point to&#8221; an object of the correct type, per
3.9.2 [basic.compound]) and thus is not suuitable for the
lvalue-to-rvalue conversion.  </P>

<BR><BR><HR><A NAME="1640"></A><H4>1640.
  
Array of abstract instance of class template
</H4><B>Section: </B>8.3.4&#160; [dcl.array]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-03-14<BR>




<P>According to 8.3.4 [dcl.array] paragraph 1, an array
declarator whose element type is an abstract class is ill-formed.
However, if the element type is a class template specialization, it
may not be known that the class is abstract; because forming an array
of an incomplete type is permitted (3.9 [basic.types] paragraphs
5-6), the class template is not required to be instantiated in order
to use it as an element type.  The expected handling if the class
template is later instantiated is unclear; should the compiler issue
an error about the earlier array array type at the point at which the
class template is instantiated?</P>

<P>This also affects overload resolution:</P>

<PRE>
  template&lt;typename&gt; struct Abstract {
    virtual void f() = 0;
    typedef int type;
  };
  template&lt;typename T&gt; char &amp;abstract_test(T[1]);      //<SPAN style="font-family:Times;font-style:italic"> #1</SPAN>
  template&lt;typename T&gt; char (&amp;abstract_test(...))[2];  //<SPAN style="font-family:Times;font-style:italic"> #2</SPAN>
  // Abstract&lt;int&gt;::type n;
  static_assert(sizeof(abstract_test&lt;Abstract&lt;int&gt;&gt;(nullptr)) == 2, "");
</PRE>

<P>Overload resolution will select #1 and fail the assertion; if the
commented line is uncommented, there is implementation variance, but
presumably #2 should be selected and satisfy the assertion.</P>

<P>These effects of completing the type are troublesome.  Would it
be better to allow array types of abstract element type and simply
prohibit creation of objects of such arrays?</P>

<P>(See also <A HREF="
     cwg_active.html#1646">issue 1646</A>.)</P>

<BR><BR><HR><A NAME="1001"></A><H4>1001.
  
Parameter type adjustment in dependent parameter types
</H4><B>Section: </B>8.3.5&#160; [dcl.fct]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2009-11-08<BR>




<P>According to 8.3.5 [dcl.fct] paragraph 5,
top-level cv-qualifiers on parameter types are deleted when
determining the function type.  It is not clear how or whether
this adjustment should be applied to parameters of function
templates when the parameter has a dependent type, however.  For
example:</P>

<PRE>
    template&lt;class T&gt; struct A {
       typedef T arr[3];
    };

    template&lt;class T&gt; void f(const typename A&lt;T&gt;::arr) { } // #1

    template void f&lt;int&gt;(const A&lt;int&gt;::arr);

    template &lt;class T&gt; struct B {
       void g(T);
    };

    template &lt;class T&gt; void B&lt;T&gt;::g(const T) { } // #2
</PRE>

<P>If the <TT>const</TT> in #1 is dropped, <TT>f&lt;int&gt;</TT> has
a parameter type of <TT>A*</TT> rather than the <TT>const A*</TT>
specified in the explicit instantiation.  If the <TT>const</TT> in
#2 is <I>not</I> dropped, we fail to match the definition of
<TT>B::g</TT> to its declaration.
</P>

<P><B>Rationale (November, 2010):</B></P>


<P>The CWG agreed that this behavior is intrinsic to the different
ways cv-qualification applies to array types and non-array types.
</P>

<P><B>Notes, January, 2012:</B></P>

<P>Additional discussion of this issue arose regarding the following
example:</P>

<PRE>
    template&lt;class T&gt; struct A {
      typedef double Point[2];
      virtual double calculate(const Point point) const = 0;
    };

    template&lt;class T&gt; struct B : public A&lt;T&gt; {
      virtual double calculate(const typename A&lt;T&gt;::Point point) const {
        return point[0];
      }
    };

    int main() {
      B&lt;int&gt; b;
      return 0;
    }
</PRE>

<P>The question is whether the member function in
<TT>B&lt;int&gt;</TT> has the same type as that in
<TT>A&lt;int&gt;</TT>: is the parameter-type-list instantiated
directly (i.e., using the adjusted types) or regenerated from the
individual parameter types? </P>

<P>(See also <A HREF="
     cwg_active.html#1322">issue 1322</A>.)</P>

<BR><BR><HR><A NAME="1668"></A><H4>1668.
  
Parameter type determination still not clear enough
</H4><B>Section: </B>8.3.5&#160; [dcl.fct]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-25<BR>




<P>According to 8.3.5 [dcl.fct] paragraph 5,</P>

<BLOCKQUOTE>

The type of a function is determined using the following rules. The type of
each parameter (including function parameter packs) is determined from its
own <I>decl-specifier-seq</I> and <I>declarator</I>. After determining the
type of each parameter, any parameter of type &#8220;array
of <TT>T</TT>&#8221; or &#8220;function returning <TT>T</TT>&#8221; is
adjusted to be &#8220;pointer to <TT>T</TT>&#8221; or &#8220;pointer to
function returning <TT>T</TT>,&#8221; respectively. After producing the
list of parameter types, any top-level <I>cv-qualifier</I>s modifying a
parameter type are deleted when forming the function type. The resulting
list of transformed parameter types and the presence or absence of the
ellipsis or a function parameter pack is the function's
<I>parameter-type-list</I>. [<I>Note:</I> This transformation does not
affect the types of the parameters. For example, <TT>int(*)(const int p,
decltype(p)*)</TT> and <TT>int(*)(int, const int*)</TT> are identical
types. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>This is not sufficiently clear to specify the intended handling of an
example like</P>

<PRE>
  void f(int a[10], decltype(a) *p );
</PRE>

<P>Should the type of <TT>p</TT> be <TT>int(*)[10]</TT>
or <TT>int**</TT>?  The latter is the intended result, but the phrase
&#8220;after determining the type of each parameter&#8221; makes it
sound as if the adjustments are performed after all the parameter
types have been determined from the <I>decl-specifier-seq</I> and
<I>declarator</I> instead of for each parameter individually.</P>

<BR><BR><HR><A NAME="325"></A><H4>325.
  
When are default arguments parsed?
</H4><B>Section: </B>8.3.6&#160; [dcl.fct.default]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Nathan Sidwell
 &#160;&#160;&#160;

 <B>Date: </B>27 Nov 2001<BR>


<P>The standard is not precise enough about when the default arguments of
member functions are parsed.  This leads to confusion over whether certain
constructs are legal or not, and the validity of certain compiler
implementation algorithms.</P>

<P>8.3.6 [dcl.fct.default] paragraph 5 says "names in the
expression are bound, and
the semantic constraints are checked, at the point where the default
argument expression appears"</P>

<P>However, further on at paragraph 9 in the same section there is an example,
where the salient parts are
<PRE>
  int b;
  class X {
    int mem2 (int i = b); // OK use X::b
    static int b;
  };
</PRE>
which appears to contradict the former constraint. At the point the default
argument expression appears in the definition of X, X::b has not been
declared, so one would expect ::b to be bound.  This of course appears to
violate 3.3.7 [basic.scope.class] paragraph 1(2) "A name N used in
a class S shall
refer to the same declaration in its context and when reevaluated in the
complete scope of S. No diagnostic is required."</P>

<P>Furthermore 3.3.7 [basic.scope.class] paragraph 1(1) gives the
 scope of names declared
in class to "consist not only of the declarative region following
the name's declarator, but also of .. default arguments ...". Thus implying
that X::b is in scope in the default argument of X::mem2 previously.</P>

<P>That previous paragraph hints at an implementation technique of saving the
token stream of a default argument expression and parsing it at the end of
the class definition (much like the bodies of functions defined in the
class).  This is a technique employed by GCC and, from its behaviour, in
the EDG front end.  The standard leaves two things unspecified. 
Firstly, is a default argument expression permitted to call a static member
function declared later in the class in such a way as to require evaluation of
that function's default arguments? I.e. is the following well formed?
<PRE>
  class A {
    static int Foo (int i = Baz ());
    static int Baz (int i = Bar ());
    static int Bar (int i = 5);
 };
</PRE>
If that is well formed, at what point does the non-sensicalness of
<PRE>
  class B {
    static int Foo (int i = Baz ());
    static int Baz (int i = Foo());
  };
</PRE>
become detected? Is it when B is complete? Is it when B::Foo or B::Baz is
called in such a way to require default argument expansion? Or is no
diagnostic required?</P>

<P>The other problem is with collecting the tokens that form the default
argument expression.  Default arguments which contain template-ids with
more than one parameter present a difficulty in determining when the
default argument finishes.  Consider,
<PRE>
  template &lt;int A, typename B&gt; struct T { static int i;};
  class C {
    int Foo (int i = T&lt;1, int&gt;::i);
  };
</PRE>
The default argument contains a non-parenthesized comma.  Is it required
that this comma is seen as part of the default argument expression and not
the beginning of another of argument declaration?  To accept this as
part of the default argument would require name lookup of T (to determine
that the '&lt;' was part of a template argument list and not a less-than
operator) before C is complete.  Furthermore, the more pathological
<PRE>
  class D {
    int Foo (int i = T&lt;1, int&gt;::i);
    template &lt;int A, typename B&gt; struct T {static int i;};
  };
</PRE>
would be very hard to accept. Even though T is declared after Foo, T is
in scope within Foo's default argument expression.</P>

<P><B>Suggested resolution:</B></P>

<P>Append the following text to 8.3.6 [dcl.fct.default] paragraph 8.</P>
<BLOCKQUOTE>
	The default argument expression of a member function declared in 
	the class definition consists of the sequence of tokens up until
	the next non-parenthesized, non-bracketed comma or close
	parenthesis.  Furthermore such default argument expressions shall
	not require evaluation of a default argument of a function
	declared later in the class.
</BLOCKQUOTE>

<P>This would make the above A, B, C and D ill formed and is in line with the
existing compiler practice that I am aware of.</P>

<P><B>Notes from the October, 2005 meeting:</B></P>

<P>The CWG agreed that the first example (<TT>A</TT>) is currently
well-formed and that it is not unreasonable to expect implementations
to handle it by processing default arguments recursively.</P>

<P><B>Additional notes, May, 2009:</B></P>

<P>Presumably the following is ill-formed:</P>

<PRE>
    int f(int = f());
</PRE>

<P>However, it is not clear what in the Standard makes it so.  Perhaps
there needs to be a statement to the effect that a default argument
only becomes usable after the complete declarator of which it is a
part.</P>

<P><B>Notes from the August, 2011 meeting:</B></P>

<P>In addition to default arguments, commas in template argument lists
also cause problems in initializers for nonstatic data members:</P>

<PRE>
    struct S {
      int n = T&lt;a,b&gt;(c);  //<SPAN style="font-family:Times;font-style:italic"> ill-formed declarator for member</SPAN> b
                          //<SPAN style="font-family:Times;font-style:italic"> or template argument?</SPAN>
    };
</PRE>

<commmittee_only><P>(This is from #16 of the
<TT>IssuesFoundImplementingC0x.pdf</TT> document on the Bloomington
wiki.</P></commmittee_only>

<P><B>Additional notes (August, 2011):</B></P>

<P>See also issues <A HREF="
     cwg_defects.html#1352">1352</A> and
<A HREF="
     cwg_active.html#361">361</A>. </P>

<P><B>Notes from the February, 2012 meeting:</B></P>

<P>It was decided to handle the question of parsing an initializer
like <TT>T&lt;a,b&gt;(c)</TT> (a <I>template-id</I> or two
declarators) in this issue and the remaining questions in <A HREF="
     cwg_active.html#361">issue 361</A>.  For this issue, a <I>template-id</I> will
only be recognized if there is a preceding declaration of a template.</P>

<BR><BR><HR><A NAME="1580"></A><H4>1580.
  
Default arguments in explicit instantiations
</H4><B>Section: </B>8.3.6&#160; [dcl.fct.default]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2012-10-29<BR>


<P>It is not clear, either from 8.3.6 [dcl.fct.default] or
14.7.2 [temp.explicit], whether it is permitted to add a default
argument in an explicit instantiation of a function template:</P>

<PRE>
  template&lt;typename T&gt; void f(T, int) { }
  template void f&lt;int&gt;(int, int=0);  //<SPAN style="font-family:Times;font-style:italic"> Permitted?</SPAN>
</PRE>

<P><B>Notes from the April, 2013 meeting:</B></P>

<P>The intent is to prohibit default arguments in explicit instantiations.</P>

<BR><BR><HR><A NAME="1716"></A><H4>1716.
  
When are default arguments evaluated?
</H4><B>Section: </B>8.3.6&#160; [dcl.fct.default]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>David Krauss
 &#160;&#160;&#160;

 <B>Date: </B>2013-07-17<BR>




<P>According to 8.3.6 [dcl.fct.default] paragraph 9,</P>

<BLOCKQUOTE>

Default arguments are evaluated each time the function is called.

</BLOCKQUOTE>

<P>Obviously, what was intended by this is that the default argument
is evaluated only if no corresponding actual argument is provided, but
this could be read as indicating that the default argument is evaluated
and discarded by every function call.</P>

<BR><BR><HR><A NAME="1552"></A><H4>1552.
  
<I>exception-specification</I>s and defaulted special member functions
</H4><B>Section: </B>8.4.2&#160; [dcl.fct.def.default]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2012-09-07<BR>


<P>The current wording of 8.4.2 [dcl.fct.def.default] paragraph 2 has some
surprising implications:</P>

<BLOCKQUOTE>

An explicitly-defaulted function may be declared <TT>constexpr</TT> only if it
would have been implicitly declared as <TT>constexpr</TT>, and may have an
explicit <I>exception-specification</I> only if it is compatible
(15.4 [except.spec]) with the <I>exception-specification</I> on
the implicit declaration.

</BLOCKQUOTE>

<P>In an example like</P>

<PRE>
  struct A {
    A&amp; operator=(A&amp;);
  };
  A&amp; A::operator=(A&amp;) = default;
</PRE>

<P>presumably the <I>exception-specification</I> of
<TT>A::operator=(A&amp;)</TT> is <TT>noexcept(false)</TT>.  However,
attempting to make that <I>exception-specification</I> explicit,</P>

<PRE>
  A&amp; A::operator=(A&amp;) noexcept(false) = default;
</PRE>

<P>is an error.  Is this intentional?</P>

<P><B>Proposed resolution (October, 2012):</B></P>

<P>Change 15.4 [except.spec] paragraph 4 as follows:</P>

<BLOCKQUOTE>

...If any declaration of a pointer to function, reference to function, or
pointer to member function has an <I>exception-specification</I>, all
occurrences of that declaration shall have a compatible
<I>exception-specification</I><SPAN style="font-weight:bold;background-color:#A0FFA0">. If a declaration of a function
has an implicit <I>exception-specification</I>, other declarations of the
function shall not specify an <I>exception-specification</I>.</SPAN> In an
explicit instantiation...

</BLOCKQUOTE>

<P>(This resolution also resolves <A HREF="
     cwg_active.html#1492">issue 1492</A>.)</P>

<P><B>Additional note (January, 2013):</B></P>

<P>The resolution conflicts with the current specification of
<TT>operator delete</TT>: in 3.7.4 [basic.stc.dynamic] paragraph 2,
the two <TT>operator delete</TT> overloads are declared with an
implicit exception specification, while in 18.6 [support.dynamic]
paragraph 1, they are declared as <TT>noexcept</TT>.

</P>

<BR><BR><HR><A NAME="1733"></A><H4>1733.
  
Return type and value for <TT>operator=</TT> with <I>ref-qualifier</I>
</H4><B>Section: </B>8.4.2&#160; [dcl.fct.def.default]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>2013-08-09<BR>




<P>8.4.2 [dcl.fct.def.default] paragraph 1 specifies that an
explicitly-defaulted function shall</P>

<BLOCKQUOTE>

have the same declared function type (except for possibly
differing <I>ref-qualifier</I>s and except that in the case of a copy
constructor or copy assignment operator, the parameter type may be
&#8220;reference to non-const <TT>T</TT>&#8221;, where <TT>T</TT> is the
name of the member function's class) as if it had been implicitly
declared...

</BLOCKQUOTE>

<P>This allows an example like</P>

<PRE>
  struct A {
    A&amp; operator=(A const&amp;) &amp;&amp; = default; 
  };
</PRE>

<P>but forbids</P>

<PRE>
  struct B {
    B&amp;&amp; operator=(B const&amp;) &amp;&amp; = default; 
  };
</PRE>

<P>which seems backward.</P>

<P>In addition, 12.8 [class.copy] paragraph 22 only specifies the
return value for implicitly-declared copy/move assignment operators,
not for explicitly-defaulted ones.</P>

<BR><BR><HR><A NAME="253"></A><H4>253.
  
Why must empty or fully-initialized const objects be initialized?
</H4><B>Section: </B>8.5&#160; [dcl.init]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>11 Jul 2000<BR>




<P>Paragraph 9 of
8.5 [dcl.init]

 says:</P>
<BLOCKQUOTE>If no initializer is specified for an object, and the object
is of (possibly cv-qualified) non-POD class type (or array thereof), the
object shall be default-initialized; if the object is of const-qualified
type, the underlying class type shall have a user-declared default constructor.
Otherwise, if no initializer is specified for an object, the object and
its subobjects, if any, have an indeterminate initial value; if the object
or any of its subobjects are of const-qualified type, the program is ill-formed.</BLOCKQUOTE>

<P>What if a const POD object has no non-static data members?
This wording requires an empty initializer for such cases:</P>

<PRE>
    struct Z {
        // no data members
        operator int() const { return 0; }
    };

    void f() {
        const Z z1;         // ill-formed: no initializer
        const Z z2 = { };   // well-formed
    }
</PRE>

<P>Similar comments apply to a non-POD const object, all of whose
non-static data members and base class subobjects have default
constructors.  Why should the class of such an object be required
to have a user-declared default constructor?</P>

<P>(See also <A HREF="
     cwg_defects.html#78">issue 78</A>.)</P>

<P><B>Additional note (February, 2011):</B></P>

<P>This issue should be brought up again in light of constexpr
constructors and non-static data member initializers.
</P>

<P><B>Notes from the August, 2011 meeting:</B></P>

<P>If the implicit default constructor initializes all subobjects,
no initializer should be required.</P>

<BR><BR><HR><A NAME="1630"></A><H4>1630.
  
Multiple default constructor templates
</H4><B>Section: </B>8.5&#160; [dcl.init]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2013-03-01<BR>




<P>It is unclear whether code like the following is supposed to be
supported or not:</P>

<PRE>
  #include &lt;iostream&gt;
  #include &lt;type_traits&gt;

  #define ENABLE_IF(...) \
    typename std::enable_if&lt;__VA_ARGS__, int&gt;::type = 0
  #define PRINT_VALUE(...) \
    std::cout &lt;&lt; #__VA_ARGS__ " = " &lt;&lt; __VA_ARGS__ &lt;&lt; std::endl

  struct undefined {};

  template &lt;class T&gt;
    undefined special_default_value(T *);

  template &lt;class T&gt;
    struct has_special_default_value :
      std::integral_constant
      &lt;
        bool,
        !std::is_same
          &lt;
            decltype(special_default_value((T *)0)),
            undefined
          &gt;{}
      &gt; {};

  template &lt;class T&gt; struct X {
    template &lt;class U = T, ENABLE_IF(!has_special_default_value&lt;U&gt;{})&gt;
      X() : value() {}
    template &lt;class U = T, ENABLE_IF(has_special_default_value&lt;U&gt;{})&gt;
      X() : value(special_default_value((T *)0)) {}
    T value;
  };

  enum E {
    e1 = 1,
    e2 = 2
  };

  E special_default_value(E *) { return e1; }

  int main() {
    X&lt;int&gt; x_int;
    X&lt;E&gt; x_E;
    PRINT_VALUE(x_int.value);
    PRINT_VALUE(x_E.value);

    PRINT_VALUE(X&lt;int&gt;().value);
    PRINT_VALUE(X&lt;E&gt;().value);
  }
</PRE>

<P>The intent is that <TT>X&lt;int&gt;</TT> should call the first default
constructor and <TT>X&lt;E&gt;</TT> should call the second.</P>

<P>If this is intended to work, the rules for making it do so are not
clear; current wording reads as if a class can have only a single
default constructor, and there appears to be no mechanism for using
overload resolution to choose between variants.</P>



<BR><BR><HR><A NAME="1622"></A><H4>1622.
  
Empty aggregate initializer for union
</H4><B>Section: </B>8.5.1&#160; [dcl.init.aggr]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2013-02-14<BR>


<P>According to 8.5.1 [dcl.init.aggr] paragraph 15,</P>

<BLOCKQUOTE>

When a union is initialized with a brace-enclosed initializer, the braces
shall only contain an <I>initializer-clause</I> for the first non-static
data member of the union.

</BLOCKQUOTE>

<P>This would appear to preclude using <TT>{}</TT> as the initializer for a
union, which would otherwise have reasonable semantics.  Is there a reason
for this restriction?</P>

<P>Also, paragraph 7 reads,</P>

<BLOCKQUOTE>

If there are fewer <I>initializer-clause</I>s in the list than there are
members in the aggregate, then each member not explicitly initialized shall
be initialized from an empty initializer list (8.5.4 [dcl.init.list]).

</BLOCKQUOTE>

<P>There should presumably be special treatment for unions, so that only
a single member is initialized in such cases.</P>

<P>(See also <A HREF="
     cwg_defects.html#1460">issue 1460</A>.)</P>

<BR><BR><HR><A NAME="1304"></A><H4>1304.
  
Omitted array bound with string initialization
</H4><B>Section: </B>8.5.2&#160; [dcl.init.string]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2011-04-26<BR>




<P>The example in 8.5.2 [dcl.init.string] paragraph
1 says,</P>

<BLOCKQUOTE>

<PRE>
  char msg[] = "Syntax error on line %s\n";
</PRE>

<P>shows a character array whose members are initialized with a
<I>string-literal</I>.  Note that because <TT>'\n'</TT> is a single
character and because a trailing <TT>'\0'</TT> is appended,
<TT>sizeof(msg)</TT> is <TT>25</TT>.
</P>

</BLOCKQUOTE>

<P>However, there appears to be no normative specification of how the
size of the array is to be calculated.</P>

<BR><BR><HR><A NAME="1414"></A><H4>1414.
  
Binding an rvalue reference to a reference-unrelated lvalue
</H4><B>Section: </B>8.5.3&#160; [dcl.init.ref]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2011-11-09<BR>




<P>Currently an attempt to bind an rvalue reference to a
reference-unrelated lvalue succeeds, binding the reference to a
temporary initialized from the lvalue by copy-initialization.  This
appears to be intentional, as the accompanying example contains the
lines</P>

<PRE>
    int i3 = 2;
    double&amp;&amp; rrd3 = i3;  //<SPAN style="font-family:Times;font-style:italic"> </SPAN>rrd3<SPAN style="font-family:Times;font-style:italic"> refers to temporary with value </SPAN>2.0
</PRE>

<P>This violates the expectations of some who expect that rvalue
references can be initialized only with rvalues.  On the other
hand, it is parallel with the handling of an lvalue
reference-to-const (and is handled by the same wording).  It also
can add efficiency without requiring existing code to be rewritten:
the implicitly-created temporary can be moved from, just as if the
call had been rewritten to create a prvalue temporary from the
lvalue explicitly.</P>

<P>On a related note, assuming the binding is permitted, the intent of
the overload tiebreaker found in 13.3.3.2 [over.ics.rank]
paragraph 3 is not clear:</P>

<UL><LI><P>Standard conversion sequence <TT>S1</TT> is a better conversion
sequence than standard conversion sequence <TT>S2</TT> if</P></LI>

<UL><LI><P>...</P></LI>

<LI><P><TT>S1</TT> and <TT>S2</TT> are reference bindings
(8.5.3 [dcl.init.ref]) and neither refers to an implicit
object parameter of a non-static member function declared without
a <I>ref-qualifier</I>, and <TT>S1</TT> binds an rvalue reference
to an rvalue and <TT>S2</TT> binds an lvalue reference.</P></LI>

</UL>

</UL>

<P>At question is what &#8220;to an rvalue&#8221; means here.  If it
is referring to the value category of the initializer itself,
before conversions, then the supposed performance advantage of
the binding under discussion does not occur because the competing
rvalue and lvalue reference overloads will be ambiguous:</P>

<PRE>
    void f(int&amp;&amp;);    //<SPAN style="font-family:Times;font-style:italic"> #1</SPAN>
    void f(const int&amp;);
    void g(double d) {
        f(d);         //<SPAN style="font-family:Times;font-style:italic"> ambiguous: #1 does not bind to an rvalue</SPAN>
    }
</PRE>

<P>On the other hand, if &#8220;to an rvalue&#8221; refers to the
actual object to which the reference is bound, i.e., to the temporary
in the case under discussion, the phrase would seem to be vacuous because
an rvalue reference can never bind directly to an lvalue.</P>

<P><B>Notes from the February, 2012 meeting:</B></P>

<P>CWG agreed that the binding rules are correct, allowing creation of
a temporary when binding an rvalue reference to a non-reference-related
lvalue.  The phrase &#8220;to an rvalue&#8221; in
13.3.3.2 [over.ics.rank] paragraph 3 is a leftover from before
binding an rvalue reference to an lvalue was prohibited and should be
removed. A change is also needed to handle the following case:</P>

<PRE>
    void f(const char (&amp;)[1]);         //<SPAN style="font-family:Times;font-style:italic"> #1</SPAN>
    template&lt;typename T&gt; void f(T&amp;&amp;);  //<SPAN style="font-family:Times;font-style:italic"> #2</SPAN>
    void g() {
      f("");                           //<SPAN style="font-family:Times;font-style:italic">calls #2, should call #1</SPAN>
    }
</PRE>

<P><B>Additional note (October, 2012):</B></P>

<P>Removing &#8220;to an rvalue,&#8221; as suggested, would have the
effect of negating the preference for binding a function lvalue to an
lvalue reference instead of an rvalue reference because the case would
now fall under the preceding bullet of 13.3.3.2 [over.ics.rank]
paragraph 3 bullet 1, sub-bullets 4 and 5:</P>

<BLOCKQUOTE>

<P>Two implicit conversion sequences of the same form are
indistinguishable conversion sequences unless one of the following
rules applies:</P>

<UL><LI><P>Standard conversion sequence <TT>S1</TT> is a better conversion sequence than
standard conversion sequence <TT>S2</TT> if</P></LI>

<UL><LI><P>...</P></LI>

<LI><P><TT>S1</TT> and <TT>S2</TT> are reference bindings
(8.5.3 [dcl.init.ref]) and neither refers to an implicit object
parameter of a non-static member function declared without a
<I>ref-qualifier</I>, and <TT>S1</TT> binds an rvalue reference to an
rvalue and <TT>S2</TT> binds an lvalue reference... or, if not that,</P></LI>

<LI><P><TT>S1</TT> and <TT>S2</TT> are reference bindings
(8.5.3 [dcl.init.ref]) and <TT>S1</TT> binds an lvalue reference
to a function lvalue and <TT>S2</TT> binds an rvalue reference to a
function lvalue.</P></LI>

</UL>

</UL>

</BLOCKQUOTE>

<P>Presumably if the suggested resolution is adopted, the order of these
two bullets should be inverted.</P>

<BR><BR><HR><A NAME="1571"></A><H4>1571.
  
cv-qualification for indirect reference binding via conversion function
</H4><B>Section: </B>8.5.3&#160; [dcl.init.ref]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2012-02-06<BR>


<P>In the case of indirect reference binding, 8.5.3 [dcl.init.ref]
paragraph 5 only requires that the cv-qualification of the referred-to
type be the same or greater than that of the initializer expression
when the types are reference-related.  This leads to the following
anomaly:</P>

<PRE>
  class A {
  public:
    operator volatile int &amp;();
  };
  A a;

  const int &amp; ir1a = a.operator volatile int&amp;(); //<SPAN style="font-family:Times;font-style:italic"> error!</SPAN>
  const int &amp; ir2a = a; //<SPAN style="font-family:Times;font-style:italic"> allowed! </SPAN>ir = a.operator volatile int&amp;();
</PRE>

<P>Is this intended?</P>

<P><B>Notes from the April, 2013 meeting:</B></P>

<P>CWG felt that the declaration of <TT>ir2a</TT> should also be an error.</P>

<BR><BR><HR><A NAME="1572"></A><H4>1572.
  
Incorrect example for rvalue reference binding via conversion function
</H4><B>Section: </B>8.5.3&#160; [dcl.init.ref]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2012-10-15<BR>


<P>The example just before the final bullet of 8.5.4 [dcl.init.list]
paragraph 5 is incorrect.  It reads, in part,</P>

<PRE>
  struct X {
    operator int&amp;();
  } x;
  int&amp;&amp; rri2 = X(); //<SPAN style="font-family:Times;font-style:italic"> error: lvalue-to-rvalue conversion applied to the</SPAN>
                    //<SPAN style="font-family:Times;font-style:italic"> result of </SPAN>operator int&amp;
</PRE>

<P>In fact, according to 13.3.1.6 [over.match.ref] (as clarified
by the proposed resolution of <A HREF="
     cwg_defects.html#1328">issue 1328</A>,
although the intent was arguably the same for the previous wording),
<TT>X::operator int&amp;()</TT> is not a candidate for the initialization
of <TT>rri2</TT>, so the case falls into the last bullet, creating an
<TT>int</TT> temporary.</P>

<P>It is not clear whether the lvalue-to-rvalue conversion whose
prohibition is intended to be illustrated by that example could actually
occur, given the specification of candidate functions in
13.3.1.6 [over.match.ref].</P>

<BR><BR><HR><A NAME="1467"></A><H4>1467.
  
List-initialization of aggregate from same-type object
</H4><B>Section: </B>8.5.4&#160; [dcl.init.list]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2012-02-06<BR>




<P>The current list-initialization rules do not provide for
list-initialization of an aggregate from an object of the same type:</P>

<PRE>
  struct X {
    X() = default;
    X(const X&amp;) = default;
  #ifdef OK
    X(int) { }
  #endif
  };

  X x;
  X x2{x}; //<SPAN style="font-family:Times;font-style:italic"> error, </SPAN>{x}<SPAN style="font-family:Times;font-style:italic"> is not a valid aggregate initializer for </SPAN>X<SPAN style="font-family:Times;font-style:italic"></SPAN>
</PRE>

<P><U>Suggested resolution:</U></P>

<P>Change 8.5.4 [dcl.init.list] paragraph 3 as follows:</P>

<BLOCKQUOTE>

<P>List-initialization of an object or reference of type <TT>T</TT> is
defined as follows:
</P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If <TT>T</TT> is a class type and the
initializer list has a single element of type <I>cv</I> <TT>T</TT> or
a class type derived from <TT>T</TT>, the object is initialized from
that element.</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">If</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">Otherwise, if</SPAN> T is an aggregate...</P></LI>

</UL>

</BLOCKQUOTE>

<P><B>Additional notes (September, 2012):</B></P>

<commmittee_only><P>(See messages <A href="
   http://accu.org/cgi-bin/wg21/message?wg=core&amp;msg=22368">22368</A>, <A href="
   http://accu.org/cgi-bin/wg21/message?wg=core&amp;msg=22371">22371</A>
through <A href="
   http://accu.org/cgi-bin/wg21/message?wg=core&amp;msg=22373">22373</A>, <A href="
   http://accu.org/cgi-bin/wg21/message?wg=core&amp;msg=22388">22388</A>, and <A href="
   http://accu.org/cgi-bin/wg21/message?wg=core&amp;msg=22494">22494</A>.)
</P></commmittee_only>

<P>It appears that 13.3.3.1.5 [over.ics.list] will also need
to be updated in parallel with this change.  Alternatively, it may be
better to change 8.5.1 [dcl.init.aggr] instead of
8.5.4 [dcl.init.list] and 13.3.3.1.5 [over.ics.list].</P>

<P>In a related note, given</P>

<PRE>
  struct NonAggregate {
    NonAggregate() {}
  };

  struct WantsIt {
    WantsIt(NonAggregate);
  };

  void f(NonAggregate n);
  void f(WantsIt);

  int main() {
    NonAggregate n;
    //<SPAN style="font-family:Times;font-style:italic"> ambiguous!</SPAN>
    f({n});
  }
</PRE>

<P>13.3.3.1.5 [over.ics.list] paragraph 3 says that the call to
<TT>f(NonAggregate)</TT> is a user-defined conversion, the same as the
call to <TT>f(WantsIt)</TT> and thus ambiguous.  Also,</P>

<PRE>
    NonAggregate n;
    //<SPAN style="font-family:Times;font-style:italic"> #1 </SPAN>(n -&gt; NonAggregate<SPAN style="font-family:Times;font-style:italic"> = Identity conversion)</SPAN>
    NonAggregate m{n};
    //<SPAN style="font-family:Times;font-style:italic"> #2 </SPAN>({n} -&gt; NonAggregate<SPAN style="font-family:Times;font-style:italic"> = User-defined conversion}</SPAN>
    //<SPAN style="font-family:Times;font-style:italic"> (copy-ctor not considered according to 13.3.3.1 [over.best.ics] paragraph 4)</SPAN>
    NonAggregate m{{n}};
</PRE>

<P>Finally, the suggested resolution simply says &#8220;initialized
from,&#8221; without specifying whether that means direct initialization
or copy initialization.  It should be explicit about which is intended,
e.g., if it reflects the kind of list-initialization being done.</P>

<BR><BR><HR><A NAME="1490"></A><H4>1490.
  
List-initialization from a string literal
</H4><B>Section: </B>8.5.4&#160; [dcl.init.list]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2012-03-29<BR>


<P>Initialization of an array of characters from a string literal is
handled by the third bullet of 8.5 [dcl.init] paragraph 16,
branching off to 8.5.2 [dcl.init.string].  However, list
initialization is handled by the first bullet, branching off to
8.5.4 [dcl.init.list], and there is no corresponding special case
in 8.5.4 [dcl.init.list] paragraph 3 for an array of characters
initialized by a brace-enclosed string literal.  That is, an
initialization like</P>

<PRE>
  char s[4]{"abc"};
</PRE>

<P>is ill-formed, which could be surprising.  Similarly,</P>

<PRE>
  std::initializer_list&lt;char&gt;{"abc"};
</PRE>

<P>is plausible but also not permitted.</P>

<P><B>Notes from the October, 2012 meeting:</B></P>

<P>CWG agreed that the first example should be permitted, but not the
second.</P>

<BR><BR><HR><A NAME="1518"></A><H4>1518.
  
Explicit default constructors and copy-list-initialization
</H4><B>Section: </B>8.5.4&#160; [dcl.init.list]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2012-07-08<BR>




<P>Consider the following example:</P>

<PRE>
  struct A {
   explicit A() = default;
  };

  struct B : A {
   explicit B() = default;
  };

  struct C {
   explicit C();
  };

  struct D : A {
   C c;
   explicit D() = default;
  };

  template&lt;typename T&gt; void f() {
   T t = {};
  }
  template&lt;typename T&gt; void g() {
   void x(T t);
   x({});
  }
</PRE>

<P>The question is whether <TT>f&lt;B&gt;</TT>, f<TT>&lt;C&gt;</TT>,
<TT>f&lt;D&gt;</TT>, <TT>g&lt;B&gt;</TT>, <TT>g&lt;C&gt;</TT>, and
<TT>g&lt;D&gt;</TT> are well-formed or ill-formed.
</P>

<P>The crux here is whether 13.3.1.7 [over.match.list] is the
governing law in each of these cases. If it is, the initialization is
ill-formed, because copy-list-initialization has selected an explicit
constructor. The standard seems clear that <TT>f&lt;A&gt;</TT> and
<TT>g&lt;A&gt;</TT> are valid (because <TT>A</TT> is an aggregate, so
13.3.1.7 [over.match.list] is not reached nor applicable),
<TT>f&lt;B&gt;</TT> is valid (because value-initialization does not
call the default constructor, so 13.3.1.7 [over.match.list] is not
reached), and that <TT>g&lt;B&gt;</TT>, <TT>g&lt;C&gt;</TT>, and
<TT>g&lt;D&gt;</TT> are ill-formed (because 13.3.1.7 [over.match.list] is reached from 13.3.3.1.5 [over.ics.list] and
selects an explicit constructor). The difference between
<TT>f&lt;B&gt;</TT> and <TT>g&lt;B&gt;</TT> is troubling.
</P>

<P>For <TT>f&lt;C&gt;</TT> and <TT>f&lt;D&gt;</TT>, it's not clear
whether the default constructor call within value-initialization
within list-initialization uses 13.3.1.7 [over.match.list] &#8212;
but some form of overload resolution seems to be implied, since
presumably we want to apply SFINAE to variadic constructor templates,
diagnose classes which have multiple default constructors through the
addition of default arguments, and the like.
</P>

<P>It has been suggested that perhaps we are supposed to reach
13.3.1.7 [over.match.list] for an empty initializer list for a
non-aggregate class with a default constructor only when we're coming
from 13.3.3.1.5 [over.ics.list], and not when 8.5.4 [dcl.init.list] delegates to value-initialization. That would make all
the <TT>f</TT>s valid, but <TT>g&lt;B&gt;</TT>, <TT>g&lt;C&gt;</TT>,
and <TT>g&lt;D&gt;</TT> ill-formed.
</P>

<P>12.3.1 [class.conv.ctor] paragraph 2 says explicit constructors
are only used for direct-initialization or casts, which argues for at
least <TT>f&lt;C&gt;</TT>, <TT>f&lt;D&gt;</TT>, <TT>g&lt;C&gt;</TT>
and <TT>g&lt;D&gt;</TT> being ill-formed.
</P>



<BR><BR><HR><A NAME="1565"></A><H4>1565.
  
Copy elision and lifetime of <TT>initializer_list</TT> underlying array
</H4><B>Section: </B>8.5.4&#160; [dcl.init.list]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>2012-10-10<BR>




<P>If an <TT>initializer_list</TT> object is copied and the copy
is elided, is the lifetime of the underlying array object extended?
E.g.,</P>

<PRE>
  void f() {
    std::initializer_list&lt;int&gt; L =
        std::initializer_list&lt;int&gt;{1, 2, 3}; //<SPAN style="font-family:Times;font-style:italic"> Lifetime of array extended?</SPAN>
  }
</PRE>

<P>The current wording is not clear.</P>

<P><B>Notes from the October, 2012 meeting:</B></P>

<P>The consensus of CWG was that the behavior should be the same,
regardless of whether the copy is elided or not.</P>

<BR><BR><HR><A NAME="1496"></A><H4>1496.
  
Triviality with deleted and missing default constructors
</H4><B>Section: </B>9.1&#160; [class.name]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2012-04-25<BR>




<P>A default constructor that is defined as deleted is trivial, according
to 12.1 [class.ctor] paragraph 5. This means that, according
to 9 [class] paragraph 6, such a class can be trivial.
If, however, the class has no default constructor because it has a
user-declared constructor, the class is not trivial.  Since both cases
prevent default construction of the class, it is not clear why there is
a difference in triviality between the cases.</P>

<P><B>Notes from the October, 2012 meeting:</B></P>

<P>It was observed that this issue was related to <A HREF="
     cwg_active.html#1344">issue 1344</A>, as the current specification allows adding
a default constructor by adding default arguments to the definition of
a constructor.  The resolution of that issue should also resolve this
one.</P>

<P><B>Notes from the September, 2013 meeting:</B></P>

<P>It was decided to resolve <A HREF="
     cwg_active.html#1344">issue 1344</A>
separately from this issue, so this issue now requires its own
resolution.</P>

<BR><BR><HR><A NAME="1341"></A><H4>1341.
  
Bit-field initializers
</H4><B>Section: </B>9.2&#160; [class.mem]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>2011-08-10<BR>




<P>The grammar for <I>member-declarator</I> (9.2 [class.mem])
does not, but should, allow for a <I>brace-or-equal-initializer</I> on
a bit-field declarator.</P>

<BR><BR><HR><A NAME="1397"></A><H4>1397.
  
Class completeness in non-static data member initializers
</H4><B>Section: </B>9.2&#160; [class.mem]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2011-09-23<BR>




<P>In Bloomington there was general agreement that given a class
that uses non-static data member initializers, the
exception-specification for the default constructor depends on
whether those initializers are noexcept.  However, according to
9.2 [class.mem] paragraph 2, the class is regarded as
complete within the <I>brace-or-equal-initializer</I>s for
non-static data members.</P>

<P>This suggests that we need to finish processing the class
before parsing the NSDMI, but our direction on <A HREF="
     cwg_active.html#1351">issue 1351</A> suggests that we need to parse the
NSDMI in order to finish processing the class.  Can't have
both...</P>

<P><B>Additional note (March, 2013):</B></P>

<P>A specific example:</P>

<PRE>
  struct A {
    void *p = A{};
    operator void*() const { return nullptr; }
  };
</PRE>

<P>Perhaps the best way of addressing this would be to make it ill-formed
for a non-static data member initializer to use a defaulted constructor
of its class.</P>

<P>See also <A HREF="
     cwg_active.html#1360">issue 1360</A>.</P>

<P><B>Notes from the September, 2013 meeting:</B></P>

<P>One approach that might be considered would be to parse deferred
portions lazily, on demand, and then issue an error if this results in
a cycle.</P>

<BR><BR><HR><A NAME="1672"></A><H4>1672.
  
Layout compatibility with multiple empty bases
</H4><B>Section: </B>9.2&#160; [class.mem]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-27<BR>


<P>The layout compatibility rules of 9.2 [class.mem] paragraph
16 are phrased only in terms of non-static data members, ignoring the
existence of base classes:</P>

<BLOCKQUOTE>

Two standard-layout struct (Clause 9 [class]) types are
layout-compatible if they have the same number of non-static data members
and corresponding non-static data members (in declaration order) have
layout-compatible types (3.9 [basic.types]).

</BLOCKQUOTE>

<P>However, this means that in an example like</P>

<PRE>
  struct empty {};
  struct A { char a; };
  struct also_empty : empty {};
  struct C : empty, also_empty { char c; };
  union U {
    struct X { A a1, a2; } x;
    struct Y { C c1, c2; } y;
  } u;
</PRE>

<P><TT>u.x.a2.a</TT> and <TT>u.y.c2.c</TT> must have the same address,
even though <TT>sizeof(A)</TT> would typically be 1 and
<TT>sizeof(B)</TT> would need to be at least 2 to give the
<TT>empty</TT> subobjects different addresses.</P>

<BR><BR><HR><A NAME="1693"></A><H4>1693.
  
Superfluous semicolons in class definitions
</H4><B>Section: </B>9.2&#160; [class.mem]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-05-29<BR>




<P>The grammar in 9.2 [class.mem] and 8.4.1 [dcl.fct.def.general]
paragraph 1 are (in part):</P>

<UL><I>member-declaration:</I>
<UL><I>function-definition</I> <TT>;</TT><I><SUB>opt</SUB></I>

</UL>

</UL>

<UL><I>function-definition:</I>
<UL><I>function-body</I>

</UL>

</UL>

<UL><I>function-body:</I>
<UL><TT>= default ;</TT><BR>
<TT>= delete ;</TT>

</UL>

</UL>

<P>This leads to the following curiosity:</P>

<PRE>
  struct A {
    void f1() = delete;   //<SPAN style="font-family:Times;font-style:italic"> #1, ok</SPAN>
    void f2() = delete;;  //<SPAN style="font-family:Times;font-style:italic"> #2, ok</SPAN>
    void f3() = delete;;; //<SPAN style="font-family:Times;font-style:italic"> #3, error, extraneous semicolon</SPAN>
  };
</PRE>

<P>This could be addressed by moving the semicolon into the productions
for <I>function-body</I> for the non-<TT>default</TT>/<TT>delete</TT>
forms or by adding <I>empty-declaration</I> to the list of
<I>member-declaration</I> productions, as is done with namespace-scope
declarations.</P>

<BR><BR><HR><A NAME="1283"></A><H4>1283.
  
Static data members of classes with typedef name for linkage purposes
</H4><B>Section: </B>9.4.2&#160; [class.static.data]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-29<BR>


<P>According to 9.4.2 [class.static.data] paragraph 4,</P>

<BLOCKQUOTE>

Unnamed classes and classes contained directly or indirectly within
unnamed classes shall not contain static data members.

</BLOCKQUOTE>

<P>There is no such restriction on member functions, and there is
no rationale for this difference, given that both static data members
and member functions can be defined outside a unnamed class with a
typedef name for linkage purposes.  (<A HREF="
     cwg_defects.html#406">Issue 406</A>
acknowledged the lack of rationale by removing the specious note in
9.4.2 [class.static.data] that attempted to explain the restriction
but left the normative prohibition in place.)</P>

<P>It would be more consistent to remove the restriction for classes
with a typedef name for linkage purposes.</P>

<P><B>Additional note (August, 2012):</B></P>

<P>It was observed that, since no definition of a <TT>const</TT>
static data member is required if it is not odr-used, there is no
reason to prohibit such members in an unnamed class even without a
typedef name for linkage purposes. </P>

<BR><BR><HR><A NAME="1721"></A><H4>1721.
  
Diagnosing ODR violations for static data members
</H4><B>Section: </B>9.4.2&#160; [class.static.data]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2013-07-31<BR>


<P>Describing the handling of static data members with
<I>brace-or-equal-initializer</I>s, 9.4.2 [class.static.data]
paragraph 3 says,</P>

<BLOCKQUOTE>

The member shall still be defined in a namespace scope if it is odr-used
(3.2 [basic.def.odr]) in the program and the namespace scope
definition shall not contain an initializer.

</BLOCKQUOTE>

<P>The word &#8220;shall&#8221; implies a required diagnostic, but this
is describing an ODR violation (the static data member might be defined
in a different translation unit) and thus should be &#8220;no diagnostic
required.&#8221;</P>

<BR><BR><HR><A NAME="1404"></A><H4>1404.
  
Object reallocation in unions
</H4><B>Section: </B>9.5&#160; [class.union]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2011-10-19<BR>




<P>According to 9.5 [class.union] paragraph 4,</P>

<BLOCKQUOTE>

<P>[<I>Note:</I> In general, one must use explicit destructor
calls and placement new operators to change the active member of
a union.  &#8212;<I>end note</I>] [<I>Example:</I> Consider an
object <TT>u</TT> of a union type <TT>U</TT> having non-static
data members <TT>m</TT> of type <TT>M</TT> and <TT>n</TT> of type
<TT>N</TT>. If <TT>M</TT> has a non-trivial destructor and
<TT>N</TT> has a non-trivial constructor (for instance, if they
declare or inherit virtual functions), the active member of
<TT>u</TT> can be safely switched from <TT>m</TT> to <TT>n</TT>
using the destructor and placement new operator as follows:</P>

<PRE>
  u.m.~M();
  new (&amp;u.n)  N;
</PRE>

<P>&#8212;<I>end example</I>]</P>

</BLOCKQUOTE>

<P>This pattern is only &#8220;safe&#8221; if the original object
that is being destroyed does not involve any const-qualified or
reference types, i.e., satisfies the requirements of 3.8 [basic.life]
paragraph 7, bullet 3:</P>

<UL><LI><P>the type of the original object is not
const-qualified, and, if a class type, does not contain any
non-static data member whose type is const-qualified or a
reference type</P></LI></UL>

<P>Although paragraph 4 of 9.5 [class.union] is a note and an
example, it should at least refer to the lifetime issues described
in 3.8 [basic.life].</P>

<P><B>Additional note (October, 2013):</B></P>

<P>See also <A HREF="
     cwg_active.html#1776">issue 1776</A>, which suggests
possibly changing the restriction in 3.8 [basic.life].  If
such a change is made, this issue may become moot.</P>

<BR><BR><HR><A NAME="1702"></A><H4>1702.
  
Rephrasing the definition of &#8220;anonymous union&#8221;
</H4><B>Section: </B>9.5&#160; [class.union]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-06-17<BR>




<P>9.5 [class.union] paragraph 5 defines an anonymous union as
follows:</P>

<BLOCKQUOTE>

<P>A union of the form</P>

<UL><TT>union {</TT> <I>member-specification</I> <TT>} ;</TT></UL>

<P>is called an anonymous union; it defines an unnamed object of unnamed type.</P>

</BLOCKQUOTE>

<P>It is obviously intended that a declaration like</P>

<PRE>
    static union { int i; float f; };
</PRE>

<P>is a declaration of that form (cf paragraph 6, which requires the
<TT>static</TT> keyword for anonymous unions declared in namespace
scope).  However, it would be clearer if the definition were recast
in more descriptive terms, e.g.,</P>

<BLOCKQUOTE>

An <I>anonymous union</I> is an unnamed class that is defined with
the <I>class-key</I> <TT>union</TT> in a <I>simple-declaration</I> in
which the <I>init-declarator-list</I> is omitted.  Such a
<I>simple-declaration</I> is treated as if it contained a single
declarator declaring an unnamed variable of the union's type.

</BLOCKQUOTE>

<P>(Note that this definition would require some additional tweaking to
apply to class member anonymous union declarations, since
<I>simple-declaration</I>s are not included
as <I>member-declaration</I>s.)</P>

<P>As a related point, it is not clear how the following examples
are to be treated, and there is implementation variance on some:</P>

<PRE>
   void f() { thread_local union { int a; }; }
   void g() { extern union { int b; }; }
   thread_local union { int c; }; //<SPAN style="font-family:Times;font-style:italic"> </SPAN>static<SPAN style="font-family:Times;font-style:italic"> is implied by </SPAN>thread_local
   static thread_local union { int d; };
   static const union { int e = 0; }; //<SPAN style="font-family:Times;font-style:italic"> is </SPAN>e<SPAN style="font-family:Times;font-style:italic"> const? Clang says yes, gcc says no</SPAN>
   static constexpr union { int f = 0; };
</PRE>

<BR><BR><HR><A NAME="1714"></A><H4>1714.
  
odr-use of <TT>this</TT> from a local class
</H4><B>Section: </B>9.8&#160; [class.local]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>David Krauss
 &#160;&#160;&#160;

 <B>Date: </B>2013-07-10<BR>


<P>According to 9.8 [class.local] paragraph 1,</P>

<BLOCKQUOTE>

Declarations in a local class shall not odr-use (3.2 [basic.def.odr])
a variable with automatic storage duration from an enclosing scope.

</BLOCKQUOTE>

<P>This restriction should apply as well to the <TT>this</TT> pointer
when the class is local to a non-static member function.</P>

<BR><BR><HR><A NAME="1710"></A><H4>1710.
  
Missing <TT>template</TT> keyword in <I>class-or-decltype</I>
</H4><B>Section: </B>10&#160; [class.derived]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-07-03<BR>


<P>A <I>class-or-decltype</I> is used as a <I>base-specifier</I> and
as a <I>mem-initializer-id</I> that names a base class.  It is
specified in 10 [class.derived] paragraph 1 as:</P>

<UL><I>class-or-decltype:</I>
<UL><I>nested-name-specifier<SUB>opt</SUB> class-name</I><BR>
<I>decltype-specifier</I>

</UL>

</UL>

<P>Consequently, a declaration like</P>

<PRE>
  template&lt;typename T&gt; struct D : T::template B&lt;int&gt;::template C&lt;int&gt; {};
</PRE>

<P>is ill-formed, although most implementations accept it; some actually
require the use of the <TT>template</TT> keyword, although the relevant
wording in 14.2 [temp.names] paragraph 4 only requires it in a
<I>qualified-id</I>, not in a <I>class-or-decltype</I>.  It would
probably be good to add a production like</P>

<UL><UL><I>nested-name-specifier</I> <TT>template</TT> <I>simple-template-id</I></UL></UL>

<P>to the definition of <I>class-or-decltype</I> and explicitly mention
those contexts in 14.2 [temp.names] as not requiring use of the
<TT>template</TT> keyword.</P>

<BR><BR><HR><A NAME="952"></A><H4>952.
  
Insufficient description of &#8220;naming class&#8221;
</H4><B>Section: </B>11.2&#160; [class.access.base]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>7 August, 2009<BR>




<P>The access rules in 11.2 [class.access.base] do not appear to
handle references in nested classes and outside of nonstatic member
functions correctly.  For example,</P>

<PRE>
    struct A {
        typedef int I;    //<SPAN style="font-family:Times;font-style:italic"> public</SPAN>
    };
    struct B: private A { };
    struct C: B {
        void f() {
            I i1;         //<SPAN style="font-family:Times;font-style:italic"> error: access violation</SPAN>
        }
        I i2;             //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
        struct D {
            I i3;         //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
            void g() {
                I i4;     //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
            }
        };
    };
</PRE>

<P>The reason for this discrepancy is that the naming class in
the reference to <TT>I</TT> is different in these cases.  According
to 11.2 [class.access.base] paragraph 5,</P>

<BLOCKQUOTE>

The access to a member is affected by the class in which the member is
named. This naming class is the class in which the member name was
looked up and found.

</BLOCKQUOTE>

<P>In the case of <TT>i1</TT>, the reference to <TT>I</TT> is subject
to the transformation described in 9.3.1 [class.mfct.non-static]
paragraph 3:</P>

<BLOCKQUOTE>

Similarly during name lookup, when an <I>unqualified-id</I>
(5.1 [expr.prim]) used in the definition of a member function
for class <TT>X</TT> resolves to a <TT>static</TT> member, an
enumerator or a nested type of class <TT>X</TT> or of a base class of <TT>X</TT>, the
<I>unqualified-id</I> is transformed into a
<I>qualified-id</I> (5.1 [expr.prim]) in which the
<I>nested-name-specifier</I> names the class of the member function.

</BLOCKQUOTE>

<P>As a result, the reference to <TT>I</TT> in the declaration of
<TT>i1</TT> is transformed to <TT>C::I</TT>, so that the naming class
is <TT>C</TT>, and <TT>I</TT> is inacessible in <TT>C</TT>.  In the
remaining cases, however, the transformation does not apply.  Thus,
the naming class of <TT>I</TT> in these references is <TT>A</TT>, and
<TT>I</TT> is publicly accessible in <TT>A</TT>.</P>

<P>Presumably either the definition of &#8220;naming class&#8221;
must be changed or the transformation of <I>unqualified-id</I>s must
be broadened to include all uses within the scope of a class and not
just within nonstatic member functions (and following the
<I>declarator-id</I> in the definition of a static member, per
9.4 [class.static] paragraph 4).</P>

<BR><BR><HR><A NAME="1699"></A><H4>1699.
  
Does befriending a class befriend its friends?
</H4><B>Section: </B>11.3&#160; [class.friend]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>David Krauss
 &#160;&#160;&#160;

 <B>Date: </B>2013-06-12<BR>


<P>According to 11.3 [class.friend] paragraph 2,</P>

<BLOCKQUOTE>

Declaring a class to be a friend implies that the names of private and
protected members from the class granting friendship can be accessed in
the <I>base-specifier</I>s and member declarations of the befriended class.

</BLOCKQUOTE>

<P>A <TT>friend</TT> declaraton is a <I>member-declaration</I>, but it
is not clear how far the granting of friendship goes in a <TT>friend</TT>
declaration.  For example:</P>

<PRE>
  class c {
    class n {};
    friend struct s;
  };

  struct s {
    friend class c::n;          //<SPAN style="font-family:Times;font-style:italic"> #1</SPAN>
    friend c::n g();            //<SPAN style="font-family:Times;font-style:italic"> #2</SPAN>
    friend void f() { c::n(); } //<SPAN style="font-family:Times;font-style:italic"> #3</SPAN>
  }; 
</PRE>

<P>In particular, if a friend function is defined inside the class
definition, as in #3, does its definition have access to the private
and protected members of the befriending class?  Implementations vary
on this point.</P>

<BR><BR><HR><A NAME="472"></A><H4>472.
  
Casting across protected inheritance
</H4><B>Section: </B>11.4&#160; [class.protected]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>16 Jun 2004<BR>


<P>Does the restriction in 11.4 [class.protected] apply to
upcasts across protected inheritance, too?  For instance,</P>

<PRE>
    struct B {
        int i;
    };
    struct I: protected B { };
    struct D: I {
        void f(I* ip) {
            B* bp = ip;    // well-formed?
            bp-&gt;i = 5;     // aka "ip-&gt;i = 5;"
        }
    };
</PRE>

<P>I think the rationale for the 11.4 [class.protected]
restriction applies equally well here &#8212; you don't know whether
<TT>ip</TT> points to a <TT>D</TT> object or not, so <TT>D::f</TT> can't be trusted to treat
the protected <TT>B</TT> subobject consistently with the policies of its
actual complete object type.</P>

<P>The current treatment of &#8220;accessible base class&#8221;
in 11.2 [class.access.base] paragraph 4
clearly makes the conversion from <TT>I*</TT> to <TT>B*</TT> well-formed.  I
think that's wrong and needs to be fixed.  The rationale for
the accessibility of a base class is whether &#8220;an invented
public member&#8221; of the base would be accessible at the point of
reference, although we obscured that a bit in the
reformulation; it seems to me that the invented member ought to
be considered a non-static member for this purpose and thus
subject to 11.4 [class.protected].</P>

(See also issues <A HREF="
     cwg_defects.html#385">385</A> and <A HREF="
     cwg_closed.html#471">471</A>.).

<P><B>Notes from October 2004 meeting:</B></P>

<P>The CWG tentatively agreed that casting across protective
inheritance should be subject to the additional restriction in
11.4 [class.protected].</P>



<P><B>Proposed resolution (April, 2011)</B></P>

<P>Change 11.2 [class.access.base] paragraph 4 as follows:</P>

<BLOCKQUOTE>

<P>A base class <TT>B</TT> of <TT>N</TT> is accessible at <I>R</I>, if</P>

<UL><LI><P>an invented public member of <TT>B</TT> would be a public
member of <TT>N</TT>, or</P></LI>

<LI><P><I>R</I> occurs in a member or friend of class <TT>N</TT>, and
an invented public member of <TT>B</TT> would be a private or
protected member of <TT>N</TT>, or</P></LI>

<LI><P><I>R</I> occurs in a member or friend of a class <TT>P</TT>
derived from <TT>N</TT>, and an invented public member of <TT>B</TT>
would be a private <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">(but not a</SPAN> protected
<SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Footnote:</I> A protected invented member is disallowed here
for the same reason the additional check of 11.4 [class.protected]
is applied to member access: it would allow casting a pointer to a
derived class to a protected base class that might be a subobject of
an object of a class that is different from the class context in which
the reference occurs.  &#8212;<I>end footnote</I>])</SPAN> member of
<TT>P</TT>, or</P></LI>

<LI><P>there exists a class <TT>S</TT> such that <TT>B</TT> is a base
class of <TT>S</TT> accessible at <I>R</I> and <TT>S</TT> is a base
class of <TT>N</TT> accessible at <I>R</I>.</P></LI>

</UL>

<P>[<I>Example:</I></P>

<PRE>
    class B {
    public:
      int m;
    };

    class S: private B {
      friend class N;
    };
    class N: private S {
      void f() {
        B* p = this;    // <SPAN style="font-family:Times;font-style:italic">OK because class </SPAN>S<SPAN style="font-family:Times;font-style:italic"> satisfies the fourth condition</SPAN>
                        // <SPAN style="font-family:Times;font-style:italic">above: </SPAN>B<SPAN style="font-family:Times;font-style:italic"> is a base class of </SPAN>N<SPAN style="font-family:Times;font-style:italic"> accessible in </SPAN>f()<SPAN style="font-family:Times;font-style:italic"> because</SPAN>
                        // B<SPAN style="font-family:Times;font-style:italic"> is an accessible base class of </SPAN>S<SPAN style="font-family:Times;font-style:italic"> and </SPAN>S<SPAN style="font-family:Times;font-style:italic"> is an accessible</SPAN>
                        // <SPAN style="font-family:Times;font-style:italic">base class of </SPAN>N.
      }
    };
<SPAN style="font-weight:bold;background-color:#A0FFA0">
    class N2: protected B { };

    class P2: public N2 {
      void f2(N2* n2p) {
        B* bp = n2p;    // <SPAN style="font-family:Times;font-style:italic">error: invented member would be protected and naming</SPAN>
                        // <SPAN style="font-family:Times;font-style:italic">class </SPAN>N2<SPAN style="font-family:Times;font-style:italic"> not the same as or derived from the referencing</SPAN>
                        // <SPAN style="font-family:Times;font-style:italic">class </SPAN>P2
        n2p-&gt;m = 0;     // <SPAN style="font-family:Times;font-style:italic">error (cf 11.4 [class.protected]) for the same reason</SPAN>
      }
    };</SPAN>
</PRE>

<P>&#8212;<I>end example</I>]</P>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1353"></A><H4>1353.
  
Array and variant members and deleted special member functions
</H4><B>Section: </B>12.1&#160; [class.ctor]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Sean Hunt
 &#160;&#160;&#160;

 <B>Date: </B>2011-08-16<BR>




<P>The specification of when a defaulted special member function is to
be defined as deleted sometimes overlooks variant and array members.</P>

<BR><BR><HR><A NAME="1360"></A><H4>1360.
  
<TT>constexpr</TT> defaulted default constructors
</H4><B>Section: </B>12.1&#160; [class.ctor]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2011-08-16<BR>




<P>According to 12.1 [class.ctor] paragraph 6, a defaulted
default constructor is <TT>constexpr</TT> if the corresponding
user-written constructor would satisfy the <TT>constexpr</TT>
requirements.  However, the requirements apply to the definition of
a constructor, and a defaulted constructor is defined only if it is
odr-used, leaving it indeterminate at declaration time whether the
defaulted constructor is <TT>constexpr</TT> or not.</P>

<P>(See also <A HREF="
     cwg_defects.html#1358">issue 1358</A>.)</P>

<P><B>Additional notes (February, 2013):</B></P>

<P>As an example of this issue, consider:</P>

<PRE>
  struct S {
    int i = sizeof(S);
  };
</PRE>

<P>You can't determine the value of the initializer, and thus whether the
initializer is a constant expression, until the class is complete, but you
can't complete the class without declaring the default constructor, and
whether that constructor is <TT>constexpr</TT> or not depends on whether
the member initializer is a constant expression.</P>

<P>A similar issue arises with the following example:</P>

<PRE>
  struct A {
    int x = 37;
    struct B { int x = 37; } b;
    B b2[2][3] = { { } };
  };
</PRE>

<P>This introduces an order dependency that is not specified in the
current text: determining whether the default constructor of <TT>A</TT>
is <TT>constexpr</TT> requires first determining the characteristics of
the initializer of <TT>B::x</TT> and whether <TT>B::B()</TT> is
<TT>constexpr</TT> or not.</P>

<P>The problem is exacerbated with class templates, since the current
direction of CWG is to instantiate member initializers only when they
are needed (see <A HREF="
     cwg_active.html#1396">issue 1396</A>).  For a specific
example:</P>

<PRE>
  struct S;
  template&lt;class T&gt; struct X {
    int i = T().i;
  };
  unsigned n = sizeof(X&lt;S&gt;); //<SPAN style="font-family:Times;font-style:italic"> Error?</SPAN>
  struct S { int i; };
</PRE>

<P>This also affects determining whether a class template specialization
is a literal type or not; presumably getting the right answer to that
requires instantiating the class and all its nonstatic data member
initializers.</P>

<P>See also issues <A HREF="
     cwg_active.html#1397">1397</A> and <A HREF="
     cwg_active.html#1594">1594</A>.</P>

<P><B>Notes from the September, 2013 meeting:</B></P>

<P>This issue should be resolved together with
<A HREF="
     cwg_active.html#1397">issue 1397</A>.</P>

<BR><BR><HR><A NAME="1623"></A><H4>1623.
  
Deleted default union constructor and member initializers
</H4><B>Section: </B>12.1&#160; [class.ctor]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Vinny Romano
 &#160;&#160;&#160;

 <B>Date: </B>2013-02-15<BR>




<P>According to 12.1 [class.ctor] paragraph 5,</P>

<BLOCKQUOTE>

<P>A defaulted default constructor for class <TT>X</TT> is defined as
deleted if:</P>

<UL><LI><P><TT>X</TT> is a union-like class that has a variant member with
a non-trivial default constructor,</P></LI>

<LI><P>...</P></LI>

<LI><P><TT>X</TT> is a union and all of its variant members are of
const-qualified type (or array thereof),</P></LI>

<LI><P><TT>X</TT> is a non-union class and all members of any anonymous
union member are of const-qualified type (or array thereof),</P></LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<P>Because the presence of a non-static data member initializer is the
moral equivalent of a <I>mem-initializer</I>, these rules should
probably be modified not to define the generated constructor as
deleted when a union member has a non-static data member initializer.
(Note the non-normative references in 9.5 [class.union]
paragraphs 2-3 and 7.1.6.1 [dcl.type.cv] paragraph 2 that
would also need to be updated if this restriction is changed.)</P>

<P>It would also be helpful to add a requirement to 9.5 [class.union]
requiring either a non-static data member initializer or a user-provided
constructor if all the members of the union have const-qualified types.</P>

<P>On a more general note, why is the default constructor defined as
deleted just because a member has a non-trivial default constructor?  The
union itself doesn't know which member is the active one, and default
construction won't initialize any members (assuming
no <I>brace-or-equal-initializer</I>).  It is up to the &#8220;owner&#8221;
of the union to control the lifetime of the active member (if any), and
requiring a user-provided constructor is forcing a design pattern that
doesn't make sense.  Along the same lines, why is the default destructor
defined as deleted just because a member has a non-trivial destructor?  I
would agree with this restriction if it only applied when the union also
has a user-provided constructor.</P>

<P>See also issues <A HREF="
     cwg_defects.html#1460">1460</A>,
<A HREF="
     cwg_defects.html#1562">1562</A>, <A HREF="
     cwg_defects.html#1587">1587</A>,
and <A HREF="
     cwg_active.html#1621">1621</A>.</P>


<BR><BR><HR><A NAME="1658"></A><H4>1658.
  
Deleted default constructor for abstract class via destructor
</H4><B>Section: </B>12.1&#160; [class.ctor]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-08-26<BR>


<P>While reviewing the resolution of <A HREF="
     cwg_active.html#1611">issue 1611</A>,
it was noticed that the final bullet of 12.1 [class.ctor]
paragraph 4 has a similar issue:</P>

<BLOCKQUOTE>

<P>...A defaulted default constructor for class <TT>X</TT> is defined as
deleted if:</P>

<UL><LI><P>...</P></LI>

<LI><P>any direct or virtual base class or non-static data member has a type with
a destructor that is deleted or inaccessible from the defaulted default
constructor.</P></LI>

</UL>

</BLOCKQUOTE>

<P>Presumably destructors for virtual bases of abstract classes should
not be considered in making this determination.</P>



<P>A question was also raised regarding whether odr-use is correctly
defined for destructors of virtual bases of abstract classes.
3.2 [basic.def.odr] paragraph 3 simply refers to
12.4 [class.dtor], where the relevant passage (paragraph 8)
reads,</P>

<BLOCKQUOTE>

After executing the body of the destructor and destroying any automatic
objects allocated within the body, a destructor for class <TT>X</TT> calls
the destructors for <TT>X</TT>'s direct non-variant non-static data
members, the destructors for <TT>X</TT>'s direct base classes and,
if <TT>X</TT> is the type of the most derived class
(12.6.2 [class.base.init]), its destructor calls the destructors
for <TT>X</TT>'s virtual base classes.

</BLOCKQUOTE>

<P>It could be argued, particularly in light of the reference to
12.6.2 [class.base.init], that this is clear enough that the
destructor for an abstract class does not invoke destructors for its
virtual bases, but a note to that effect might be helpful.</P>

<BR><BR><HR><A NAME="1299"></A><H4>1299.
  
&#8220;Temporary objects&#8221; vs &#8220;temporary expressions&#8221;
</H4><B>Section: </B>12.2&#160; [class.temporary]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2011-04-16<BR>




<P>The Standard is insufficiently precise in dealing with temporaries.
It is not always clear when the term &#8220;temporary&#8221; is referring
to an expression whose result is a prvalue and when it is referring to
a temporary object.</P>

<P>(See also <A HREF="
     cwg_closed.html#1568">issue 1568</A>.)</P>

<BR><BR><HR><A NAME="1651"></A><H4>1651.
  
Lifetime extension of temporary via reference to subobject
</H4><B>Section: </B>12.2&#160; [class.temporary]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-15<BR>


<P>The resolution of issues <A HREF="
     cwg_defects.html#616">616</A> and
<A HREF="
     cwg_defects.html#1213">1213</A>, making the result of a member access or
subscript expression applied to a prvalue an xvalue, means that binding a
reference to such a subobject of a temporary does not extend the
temporary's lifetime. 12.2 [class.temporary] should be revised to ensure
that it does.</P>

<BR><BR><HR><A NAME="1695"></A><H4>1695.
  
Lifetime extension via <I>init-capture</I>
</H4><B>Section: </B>12.2&#160; [class.temporary]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-05-31<BR>




<P>If an <I>init-capture</I> binds a const reference to a temporary,
is the lifetime of the temporary extended to match that of the lambda?
For example,</P>

<PRE>
   struct S { ~S(); };
   const S f();
   auto &amp;&amp;lambda = [&amp;x(f())] () -&gt; auto&amp; { return x; };
   auto &amp;y = lambda(); //<SPAN style="font-family:Times;font-style:italic"> ok?</SPAN>
</PRE>

<P><B>Notes from the September, 2013 meeting:</B></P>

<P>CWG agreed that there is no lifetime extension in this example.</P>

<BR><BR><HR><A NAME="1697"></A><H4>1697.
  
Lifetime extension and copy elision
</H4><B>Section: </B>12.2&#160; [class.temporary]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-06-01<BR>




<P>In an example like,</P>

<PRE>
  struct S { ~S(); };
  struct X { X(); X(const X&amp;); };
  struct T { S &amp;&amp;s; X x; };
  void f();
  void g() { T t = T{ {}, {} }; f(); }
</PRE>

<P>it appears that the current wording allows two ways of handling
this:</P>

<OL><LI><P>The copy to <TT>t</TT> in <TT>g</TT> is not elided. <TT>X(const
X&amp;)</TT> is called, then <TT>~S()</TT> is called, then <TT>f()</TT> is
called.</P></LI>

<LI>The copy to <TT>t</TT> in <TT>g</TT> is elided, so the temporary
and <TT>t</TT> are the same object. Thus, the <TT>S</TT> object's lifetime
is extended to the lifetime of the reference <TT>t.s</TT>, so
first <TT>f()</TT> is called, then <TT>~S()</TT> is called (and <TT>X(const
X&amp;)</TT> is not called).</LI>

</OL>

<P>However, EDG and g++ produce a third behavior: they do not call
<TT>X(const X&amp;)</TT>, but they destroy the <TT>S()</TT> temporary at
the end of its full-expression. The current wording does not appear to
permit this behavior, but it seems preferable that lifetime extension does
not depend on whether copy elision is done.</P>

<BR><BR><HR><A NAME="1726"></A><H4>1726.
  
Declarator operators and conversion function
</H4><B>Section: </B>12.3.2&#160; [class.conv.fct]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>2013-08-02<BR>




<P>Presumably the following example is intended to be ill-formed:</P>

<PRE>
  struct A {
    (*operator int*());
  };
  A a;
  int *x = a; //<SPAN style="font-family:Times;font-style:italic"> Ok?</SPAN>
</PRE>

<P>It is not clear, however, which rule is supposed to reject such a
<I>member-declaration</I>.</P>

<BR><BR><HR><A NAME="399"></A><H4>399.
  
Destructor lookup redux
</H4><B>Section: </B>12.4&#160; [class.dtor]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>17 Jan 2003<BR>


<P>Mark Mitchell raised a number of issues related to the resolution of
<A HREF="
     cwg_defects.html#244">issue 244</A> and of destructor lookup in general.</P>

<P><A HREF="
     cwg_defects.html#244">Issue 244</A> says:</P>
<BLOCKQUOTE>
	... in a <I>qualified-id</I> of the form:
<UL>
::<SUB>opt</SUB> <I>nested-name-specifier</I><SUB>opt</SUB>
   <I>class-name</I> :: ~ <I>class-name</I>
</UL>
	the second class-name is looked up in the same scope as the first.
</BLOCKQUOTE>
<P>But if the reference is "<TT>p-&gt;X::~X()</TT>", the first
<I>class-name</I> is looked up
in two places (normal lookup and a lookup in the class of p).  Does
the new wording mean:
<OL>
<LI>
You look up the second class-name in the scope that you found the first
one.
</LI>
<LI>You look up the second class-name using the same kind of lookup that
   found the first one (normal vs. class).
</LI>
<LI>If you did a dual lookup for the first you do a dual lookup for the
   second.
</LI>
</OL>
</P>

<P>This is a test case that illustrates the issue:</P>
<PRE>
  struct A {
    typedef A C;
  };

  typedef A B;

  void f(B* bp) {
    bp-&gt;B::~B();  // okay B found by normal lookup
    bp-&gt;C::~C();  // okay C found by class lookup
    bp-&gt;B::~C();  // B found by normal lookup C by class -- okay?
    bp-&gt;C::~B();  // C found by class lookup B by normal -- okay?
  }
</PRE>

<P>A second issue concerns destructor references when the class involved is
a template class.</P>
<PRE>
  namespace N {
    template &lt;typename T&gt; struct S {
      ~S();
    };
  }

  void f(N::S&lt;int&gt;* s) {
    s-&gt;N::S&lt;int&gt;::~S();
  }
</PRE>
<P>The issue here is that the grammar uses "~<I>class-name</I>" for destructor
names, but in this case S is a template name when looked up in N.</P>

<P>Finally, what about cases like:</P>
<PRE>
  template &lt;typename T&gt; void f () {
    typename T::B x;
    x.template A&lt;T&gt;::template B&lt;T&gt;::~B();
  }
</PRE>
<P>When parsing the template definition, what checks can be done on "~B"?</P>

<P><U>Sandor Mathe</U> adds
:</P>

<P>The standard correction for <A HREF="
     cwg_defects.html#244">issue 244</A>
(now in DR status) is still incomplete.</P>

<P>Paragraph 5 of 3.4.3 [basic.lookup.qual] is
not applicable for p-&gt;T::~T since there is no nested-name-specifier.
Section 3.4.5 [basic.lookup.classref]
describes the lookup of p-&gt;~T but p-&gt;T::~T is still not
described.  There are examples (which are non-normative) that illustrate
this sort of lookup but they still leave questions unanswered.  The
examples imply that the name after ~ should be looked up in the same
scope as the name before the :: but it is not stated.  The problem is
that the name to the left of the :: can be found in two
different scopes.  Consider the following:</P>
<PRE>
  struct S {
    struct C { ~C() { } };
  };

  typedef S::C D;

  int main() {
    D* p;
    p-&gt;C::~D();  // valid?
  }
</PRE>

<P>Should the destructor call be valid?  If there were a nested name
specifier, then D should be looked for in the same scope as C.  But
here, C is looked for in 2 different ways.  First, it is searched for in
the type of the left hand side of -&gt; and it is also looked for in the
lexical context.  It is found in one or if both, they must match.  So, C
is found in the scope of what p points at.  Do you only look for D there?
If so, this is invalid.  If not, you would then look for D in the context
of the expression and find it.  They refer to the same underlying
destructor so this is valid.  The intended resolution of the original
defect report of the standard was that the name before the :: did not
imply a scope and you did not look for D inside of C.  However, it was
not made clear whether this was to be resolved by using the same lookup
mechanism or by introducing a new form of lookup which is to look in the
left hand side if that is where C was found, or in the context of the
expression if that is where C was found.  Of course, this begs the
question of what should happen when it is found in both?  Consider
the modification to the above case when C is also found in the context
of the expression.  If you only look where you found C, is this now
valid because it is in 1 of the two scopes or is it invalid because C
was in both and D is only in 1?</P>

<PRE>
  struct S {
    struct C { ~C() { } };
  };

  typedef S::C D;
  typedef S::C C;

  int main() {
    D* p;
    p-&gt;C::~D();  // valid?
  }
</PRE>

<P>I agree that the intention of the committee is that the original test
case in this defect is broken.  The standard committee clearly thinks
that the last name before the last :: does not induce a new scope which
is our current interpretation.  However, how this is supposed to work
is not defined.  This needs clarification of the standard.</P>

<P><U>Martin Sebor</U> adds this example (September 2003), along
with errors produced by the EDG front end:</P>
<PRE>
namespace N {
    struct A { typedef A NA; };
    template &lt;class T&gt; struct B { typedef B NB; typedef T BT; };
    template &lt;template &lt;class&gt; class T&gt; struct C { typedef C NC; typedef T&lt;A&gt; CA; };
}

void foo (N::A *p)
{
    p-&gt;~NA ();
    p-&gt;NA::~NA ();
}

template &lt;class T&gt;
void foo (N::B&lt;T&gt; *p)
{
    p-&gt;~NB ();
    p-&gt;NB::~NB ();
}

template &lt;class T&gt;
void foo (typename N::B&lt;T&gt;::BT *p)
{
    p-&gt;~BT ();
    p-&gt;BT::~BT ();
}

template &lt;template &lt;class&gt; class T&gt;
void foo (N::C&lt;T&gt; *p)
{
    p-&gt;~NC ();
    p-&gt;NC::~NC ();
}

template &lt;template &lt;class&gt; class T&gt;
void foo (typename N::C&lt;T&gt;::CA *p)
{
    p-&gt;~CA ();
    p-&gt;CA::~CA ();
}

Edison Design Group C/C++ Front End, version 3.3 (Sep  3 2003 11:54:55)
Copyright 1988-2003 Edison Design Group, Inc.

"t.cpp", line 16: error: invalid destructor name for type "N::B&lt;T&gt;"
      p-&gt;~NB ();
          ^

"t.cpp", line 17: error: qualifier of destructor name "N::B&lt;T&gt;::NB" does not
          match type "N::B&lt;T&gt;"
      p-&gt;NB::~NB ();
              ^

"t.cpp", line 30: error: invalid destructor name for type "N::C&lt;T&gt;"
      p-&gt;~NC ();
          ^

"t.cpp", line 31: error: qualifier of destructor name "N::C&lt;T&gt;::NC" does not
          match type "N::C&lt;T&gt;"
      p-&gt;NC::~NC ();
              ^

4 errors detected in the compilation of "t.cpp".
</PRE>

<P><U>John Spicer:</U>
The issue here is that we're unhappy with the destructor names when doing 
semantic analysis of the template definitions (not during an
instantiation).</P>

<P>My personal feeling is that this is reasonable.  After all, why 
would you call p-&gt;~NB for a class that you just named
as N::B&lt;T&gt; and you could just say p-&gt;~B?</P>

<P><B>Additional note (September, 2004)</B></P>

<P>The resolution for <A HREF="
     cwg_defects.html#244">issue 244</A> removed
the discussion of <TT>p-&gt;N::~S</TT>, where <TT>N</TT> is a
<I>namespace-name</I>.  However, the resolution did not make this
construct ill-formed; it simply left the semantics undefined.
The meaning should either be defined or the construct made
ill-formed.</P>

<P>See also issues <A HREF="
     cwg_defects.html#305">305</A> and
<A HREF="
     cwg_defects.html#466">466</A>.</P>

<BR><BR><HR><A NAME="1492"></A><H4>1492.
  
Exception specifications on template destructors
</H4><B>Section: </B>12.4&#160; [class.dtor]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2012-04-01<BR>




<P>According to 12.4 [class.dtor] paragraph 3,</P>

<BLOCKQUOTE>

A declaration of a destructor that does not have an
<I>exception-specification</I> is implicitly considered to have the
same <I>exception-specification</I> as an implicit declaration
(15.4 [except.spec]).

</BLOCKQUOTE>

<P>The implications of this are not clear for the destructor of a
class template. For example,</P>

<PRE>
  template &lt;class T&gt; struct B: T {
    ~B();
  };
  template &lt;class T&gt; B&lt;T&gt;::~B() noexcept {}
</PRE>

<P>The implicit <I>exception-specification</I> of the in-class
declaration of the destructor depends on the characteristics of the
template argument. Does this mean that the out-of-class definition of
the destructor is ill-formed, or will it be ill-formed only in
specializations where the template argument causes the implicit
<I>exception-specification</I> to be other than <TT>noexcept</TT>?</P>

<P><B>Proposed resolution (October, 2012):</B></P>

<P>This issue is resolved by the resolution of
<A HREF="
     cwg_active.html#1552">issue 1552</A>.</P>

<P><B>Notes from the April, 2013 meeting:</B></P>

<P>This issue was approved as a DR at the April, 2013 (Bristol)
meeting, but it was not noticed that <A HREF="
     cwg_active.html#1552">issue 1552</A>
was not being moved at that time.  It is being returned to "drafting"
status pending the resolution of that issue.</P>

<BR><BR><HR><A NAME="1586"></A><H4>1586.
  
Naming a destructor via <TT>decltype</TT>
</H4><B>Section: </B>12.4&#160; [class.dtor]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Clamage
 &#160;&#160;&#160;

 <B>Date: </B>2012-11-14<BR>




<P>Use of a <I>decltype-specifier</I> to name a destructor in an
explicit destructor call is explicitly permitted in
12.4 [class.dtor] paragraph 13.  However, the most
straightforward attempt to do so, e.g.,</P>

<PRE>
  p-&gt;~decltype(*p)()
</PRE>

<P>does not work, because <TT>*p</TT> is an lvalue and thus
<TT>decltype(*p)</TT> is a reference type, not a class type.
Even simply eliminating the reference is not sufficient, because
<TT>p</TT> could be a pointer to a cv-qualified class type.</P>

<P>Either the provision for <I>decltype-specifier</I>s in explicit
destructor calls should be removed or the specification should be
expanded to allow reference and cv-qualified types to be considered as
&#8220;denot[ing] the destructor's class type.&#8221;</P>

<P><B>Notes from the April, 2013 meeting:</B></P>

<P>CWG favored replacing the existing syntax with something more flexible,
for example, <TT>p-&gt;~auto()</TT>. This new syntax would also apply to
pseudo destructors.</P>

<BR><BR><HR><A NAME="255"></A><H4>255.
  
Placement deallocation functions and lookup ambiguity
</H4><B>Section: </B>12.5&#160; [class.free]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>26 Oct 2000<BR>


<P>Paragraph 4 of 12.5 [class.free] speaks of looking up a
deallocation function.  While it is an error if a placement
deallocation function alone is found by this lookup, there seems to be
an assumption that a placement deallocation function and a usual
deallocation function can both be declared in a given class scope
without creating an ambiguity.  The normal mechanism by which
ambiguity is avoided when functions of the same name are declared in
the same scope is overload resolution; however, there is no mention of
overload resolution in the description of the lookup.  In fact, there
appears to be nothing in the current wording that handles this case.
That is, the following example appears to be ill-formed, according to
the current wording:</P>

<PRE>
    struct S {
        void operator delete(void*);
        void operator delete(void*, int);
    };
    void f(S* p) {
        delete p;    // ill-formed: ambiguous operator delete
    }
</PRE>

<P><B>Suggested resolution</B> (Mike Miller, March 2002):</P>

<P>I think you might get the right effect by replacing
the last sentence of 12.5 [class.free] paragraph 4
with something like:</P>
<BLOCKQUOTE>
After removing all placement deallocation functions,
the result of the lookup shall contain an unambiguous
and accessible deallocation function.
</BLOCKQUOTE>

<P><B>Additional notes (October, 2012):</B></P>

<P>This issue should be reconsidered in list of paper N3396, as it would
add additional overloads for allocation and deallocation functions.

</P>

<P>The term &#8220;usual deallocation function&#8221; is defined in
3.7.4.2 [basic.stc.dynamic.deallocation] paragraph 2; perhaps it could be used to
good effect in 5.3.5 [expr.delete] paragraph 7.  The specifications
in 12.5 [class.free] paragraphs 4 and 5 should probably also be
moved into 5.3.5 [expr.delete].</P>

<BR><BR><HR><A NAME="1621"></A><H4>1621.
  
Member initializers in anonymous unions
</H4><B>Section: </B>12.6.2&#160; [class.base.init]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2013-02-12<BR>


<P>The effect of a non-static data member initializer in an anonymous
union is not clearly described in the current wording.  Consider the
following example:</P>

<PRE>
  struct A {
    struct B {
      union {
        int x = 37;
      };
      union {
        int y = x + 47;  //<SPAN style="font-family:Times;font-style:italic"> Well-formed?</SPAN>
      };
    } a;
  }; 
</PRE>

<P>Does an anonymous union have a constructor that applies a non-static
data member initializer?  Or is the initialization performed by the
constructor of the class in which the anonymous union appears?  In
particular, is the reference to <TT>x</TT> in the initializer for
<TT>y</TT> well-formed or not?  If the initialization of <TT>y</TT>
is performed by <TT>B</TT>'s constructor, there is no problem because
<TT>B::x</TT> is a member of the object being initialized.  If an anonymous
union has its own constructor, <TT>B::x</TT> is just a member of the
containing class and is a reference to a non-static data member without an
object, which is ill-formed.  Implementations currently appear to take the
latter interpretation and report an error for that initializer.</P>



<P>As a further example, consider:</P>

<PRE>
  union {       //<SPAN style="font-family:Times;font-style:italic"> #1</SPAN>
    union {     //<SPAN style="font-family:Times;font-style:italic"> #2</SPAN>
      union {   //<SPAN style="font-family:Times;font-style:italic"> #3</SPAN>
        int y = 32;
      };
    };
  } a { } ;
</PRE>

<P>One interpretation might be that union #3 has a non-trivial default
constructor because of the initializer of <TT>y</TT>, which would give
union #2 a deleted default constructor, which would make the example
ill-formed.</P>

<P>As yet another example, consider:</P>

<PRE>
  union {
    union {
      int x;
    };
    union {
      int y = 3;
    };
    union {
      int z;
    };
  } a { };
</PRE>

<P>Assuming the current proposed resolution of <A HREF="
     cwg_defects.html#1502">issue 1502</A>, what is the correct interpretation of this code?  Is it
well-formed, and if so, what initialization is performed?</P>

<P>Finally, consider</P>

<PRE>
  struct S {
    union { int x = 1; };
    union { int y = 2; };
  } s{};
</PRE>

<P>Does this violate the prohibition of aggregates containing
member initializers in 8.5.1 [dcl.init.aggr] paragraph 1?</P>

<P>See also issues <A HREF="
     cwg_defects.html#1460">1460</A>,
<A HREF="
     cwg_defects.html#1562">1562</A>, <A HREF="
     cwg_defects.html#1587">1587</A>,
and <A HREF="
     cwg_active.html#1623">1623</A>.</P>

<BR><BR><HR><A NAME="1092"></A><H4>1092.
  
Cycles in overload resolution during instantiation
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-07-15<BR>




<P>Moving to always doing overload resolution for determining exception 
specifications and implicit deletion creates some unfortunate cycles:</P>

<PRE>
    template&lt;typename T&gt; struct A {
       T t;
    };

    template &lt;typename T&gt; struct B {
       typename T::U u;
    };

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

    template &lt;typename T&gt; struct D {
       C&lt;B&lt;T&gt; &gt; v;
    };

    struct E {
       typedef A&lt;D&lt;E&gt; &gt; U;
    };

    extern A&lt;D&lt;E&gt; &gt; a;
    A&lt;D&lt;E&gt; &gt; a2(a);
</PRE>

<P>If declaring the copy constructor for
<TT>A&lt;D&lt;E&gt;&gt;</TT> is part of instantiating the
class, then we need to do overload resolution on
<TT>D&lt;E&gt;</TT>, and thus <TT>C&lt;B&lt;E&gt;&gt;</TT>.
We consider <TT>C(const B&lt;E&gt;&amp;)</TT>, and therefore
look to see if there's a conversion from
<TT>C&lt;B&lt;E&gt;&gt;</TT> to <TT>B&lt;E&gt;</TT>, which
instantiates <TT>B&lt;E&gt;</TT>, which fails because it has
a field of type <TT>A&lt;D&lt;E&gt;&gt;</TT> which is
already being instantiated.</P>

<P>Even if we wait until <TT>A&lt;D&lt;E&gt;&gt;</TT> is
considered complete before finalizing the copy constructor
declaration, declaring the copy constructor for
<TT>B&lt;E&gt;</TT> will want to look at the copy
constructor for <TT>A&lt;D&lt;E&gt;&gt;</TT>, so we still
have the cycle.</P>

<P>I think that to avoid this cycle we need to short-circuit
consideration of <TT>C(const T&amp;)</TT> somehow.  But I
don't see how we can do that without breaking</P>

<PRE>
    struct F {
       F(F&amp;);
    };

    struct G;
    struct G2 {
       G2(const G&amp;);
    };

    struct G {
       G(G&amp;&amp;);
       G(const G2&amp;);
    };

    struct H: F, G { };

    extern H h;
    H h2(h);
</PRE>

<P>Here, since <TT>G</TT>'s move constructor suppresses the
implicit copy constructor, the defaulted <TT>H</TT> copy
constructor calls <TT>G(const G2&amp;)</TT> instead.  If the
move constructor did not suppress the implicit copy
constructor, I believe the implicit copy constructor would
always be viable, and therefore a better match than a
constructor taking a reference to another type.</P>

<P>So perhaps the answer is to reconsider that suppression
and then disqualify any constructor taking (a reference to)
a type other than the constructor's class from consideration
when looking up a subobject constructor in an implicitly
defined constructor.  (Or assignment operator,
presumably.)</P>

<P>Another possibility would be that when we're looking for
a conversion from <TT>C&lt;B&lt;E&gt;&gt;</TT> to
<TT>B&lt;E&gt;</TT> we could somehow avoid considering, or
even declaring, the <TT>B&lt;E&gt;</TT> copy constructor.
But that seems a bit dodgy.</P>

<P><B>Additional note (October, 2010):</B></P>

<P>An explicitly declared move constructor/op= should not suppress the
implicitly declared copy constructor/op=; it should cause it to be
deleted instead.  This should prevent a member function taking a
(reference to) an un-reference-related type from being chosen by
overload resolution in a defaulted member function.</P>

<P>And we should clarify that member functions taking
un-reference-related types are not even considered during overload
resolution in a defaulted member function, to avoid requiring their
parameter types to be complete.
</P>

<BR><BR><HR><A NAME="1491"></A><H4>1491.
  
Move construction and rvalue reference members
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2012-03-30<BR>




<P>According to 12.8 [class.copy] paragraph 11, the last bullet,
a defaulted move constructor for a class is defined as deleted if</P>

<BLOCKQUOTE>

a non-static data member or direct or virtual base class with a type
that does not have a move constructor and is not trivially copyable.

</BLOCKQUOTE>

<P>This means that an example like</P>

<PRE>
  struct S { S(); int &amp;&amp;r; } s{S()};
</PRE>

<P>is ill-formed.  This is probably not intended.</P>

<P>(Note that the February, 2012 proposed resolution for
<A HREF="
     cwg_defects.html#1402">issue 1402</A> also makes this example
ill-formed, because the move constructor is not declared and the
copy constructor is defined as deleted because of the rvalue-reference
member.)</P>

<BR><BR><HR><A NAME="1499"></A><H4>1499.
  
Missing case for deleted move assignment operator
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2012-04-27<BR>


<P>Bullet 4 of 12.8 [class.copy] paragraph 23 says that a
defaulted copy/move assignment operator is defined as deleted if the class
has</P>

<BLOCKQUOTE>

a non-static data member of class type <TT>M</TT> (or array thereof) that
cannot be copied/moved because overload resolution (13.3 [over.match]), as applied to <TT>M</TT>'s corresponding assignment operator,
results in an ambiguity or a function that is deleted or inaccessible
from the defaulted assignment operator

</BLOCKQUOTE>

<P>The intent of this is that if overload resolution fails to find a
corresponding copy/move assignment operator that can validly be called
to copy/move a member, the class's assignment operator will be defined
as deleted.  However, this wording does not cover an example like the
following:</P>

<PRE>
  struct A {
    A();
  };

  struct B {
    B();
    const A a;
  };

  typedef B&amp; (B::*pmf)(B&amp;&amp;);

  pmf p =&amp;B::operator=; 
</PRE>

<P>Here, the problem is simply that overload resolution failed to find
a callable function, which is not one of the cases listed in the current
wording.  A similar problem exists for base classes in the fifth bullet.</P>

<P><B>Additional note (January, 2013):</B></P>

<P>A similar omission exists in paragraph 11 for copy constructors.</P>

<BR><BR><HR><A NAME="1548"></A><H4>1548.
  
Copy/move construction and conversion functions
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2012-09-02<BR>




<P>The current wording of 12.8 [class.copy] paragraph 31
refers only to constructors and destructors:</P>

<BLOCKQUOTE>

When certain criteria are met, an implementation is allowed to omit
the copy/move construction of a class object, even if the constructor
selected for the copy/move operation and/or the destructor for the
object have side effects.

</BLOCKQUOTE>

<P>However, in some cases (e.g., <TT>auto_ptr</TT>) a conversion function
is also involved in the copying, and it could presumably also have visible
side effects that would be eliminated by copy elision.  (Some additional
contexts that may also require changes in this regard are mentioned in the
resolution of <A HREF="
     cwg_defects.html#535">issue 535</A>.)</P>

<P><B>Additional note (September, 2012):</B></P>

<P>The default arguments of an elided constructor can also have side
effects and should be mentioned, as well; however, the elision should
not change the odr-use status of functions and variables appearing in
those default arguments. </P>

<BR><BR><HR><A NAME="1594"></A><H4>1594.
  
Lazy declaration of special members vs overload errors
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2012-12-06<BR>




<P>The implicit declaration of a special member function sometimes
requires overload resolution, in order to select a special member to
use for base classes and non-static data members. This can be required
to determine whether the member is or would be deleted, and whether
the member is trivial, for instance. The standard appears to require
such overload resolution be performed at the end of the definition of
the class, but in practice, implementations perform it lazily. This
optimization appears to be non-conforming, in the case where overload
resolution would hit an error.  In order to enable this optimization,
such errors should be &#8220;no diagnostic required.&#8221;</P>

<P><B>Additional note (March, 2013):</B></P>

<P>See also <A HREF="
     cwg_active.html#1360">issue 1360</A>.</P>

<P><B>Notes from the September, 2013 meeting:</B></P>

<P>The problem with this approach is that hard errors (not in the
immediate context) can occur, affecting portability.  There are some
cases, such as a virtual assignment operator in the base class, where
lazy evaluation cannot be done, so it cannot be mandated.</P>

<BR><BR><HR><A NAME="1734"></A><H4>1734.
  
Nontrivial deleted copy functions
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>2013-08-09<BR>




<P>The intent was for PODs in C++11 to be a superset of C++03 PODs.
Consequently, in the following example, <TT>C</TT> should be a POD
but isn't:</P>

<PRE>
  struct A {
    const int m;
    A&amp; operator=(A const&amp;) = default; //<SPAN style="font-family:Times;font-style:italic"> deleted and trivial, so </SPAN>A<SPAN style="font-family:Times;font-style:italic"> is a</SPAN>
                                      //<SPAN style="font-family:Times;font-style:italic"> POD, as it would be in 2003</SPAN>
                                      //<SPAN style="font-family:Times;font-style:italic"> without this explicit </SPAN>op=<SPAN style="font-family:Times;font-style:italic"> decl</SPAN>
  };
  static_assert(__is_trivially_copyable(A), "");

  struct B { 
    int i; 
    B&amp; operator=(B &amp;) &amp; = default;      //<SPAN style="font-family:Times;font-style:italic"> non-trivial</SPAN>
    B&amp; operator=(B const&amp;) &amp; = default; //<SPAN style="font-family:Times;font-style:italic"> trivial</SPAN>
  };

  struct C {
    const B m;
    C&amp; operator=(C const&amp; r) = default; //<SPAN style="font-family:Times;font-style:italic"> deleted (apparently), but non-trivial (apparently)</SPAN>
    /*<SPAN style="font-family:Times;font-style:italic"> Notionally:</SPAN>
      C&amp; operator=(C const&amp; r) {
        (*this).m.operator=(r.m);
        return *this;
      }
    */
  };
  static_assert(!__is_trivially_copyable(C), "");  
</PRE>

<P>This is because of the following text from 12.8 [class.copy]
paragraph 25:</P>

<BLOCKQUOTE>

for each non-static data member of <TT>X</TT> that is of class type (or
array thereof), the assignment operator selected to copy/move that member
is trivial;

</BLOCKQUOTE>

<P>In this case, overload resolution fails, so no assignment operator
is selected, so <TT>C::operator=(const C&amp;)</TT> is non-trivial.</P>

<BR><BR><HR><A NAME="1573"></A><H4>1573.
  
Inherited constructor characteristics
</H4><B>Section: </B>12.9&#160; [class.inhctor]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2012-10-15<BR>




<P><A HREF="
     cwg_defects.html#1350">Issue 1350</A> clarified that the
<I>exception-specification</I> for an inheriting constructor is
determined like defaulted functions, but we should also say something
similar for deleted, and perhaps constexpr.</P>

<P>Also, the description of the semantics of inheriting constructors
don't seem to allow for C-style variadic functions, so the text should
be clearer that such constructors are only inherited without their
ellipsis.</P>

<BR><BR><HR><A NAME="1645"></A><H4>1645.
  
Identical inheriting constructors via default arguments
</H4><B>Section: </B>12.9&#160; [class.inhctor]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-03-18<BR>




<P>For an example like</P>

<PRE>
  struct A {
    constexpr A(int, float = 0);
    explicit A(int, int = 0);
    A(int, int, int = 0) = delete;
  };

  struct B : A {
    using A::A;
  };
</PRE>

<P>it is not clear from 12.9 [class.inhctor] what
should happen: is <TT>B::B(int)</TT> <TT>constexpr</TT>
and/or <TT>explicit</TT>?  Is <TT>B::B(int,
int)</TT> <TT>explicit</TT> and/or deleted?  Although the
rationale given in the note in paragraph 7,</P>

<BLOCKQUOTE>

If two <I>using-declaration</I>s declare inheriting
constructors with the same signatures, the program is
ill-formed (9.2 [class.mem],
13.1 [over.load]), because an implicitly-declared
constructor introduced by the first <I>using-declaration</I>
is not a user-declared constructor and thus does not
preclude another declaration of a constructor with the same
signature by a subsequent <I>using-declaration</I>.

</BLOCKQUOTE>

<P>might be thought to apply, paragraph 1 talks about
a <I>set</I> of candidate constructors based on their
parameter types, so presumably such a set would contain only
a single declaration of <TT>A::A(int)</TT> and one
for <TT>A::A(int, int)</TT>.  The constructor
characteristics of that declaration, however, are not
specified.</P>

<P>One possibility might be to declare such a constructor, resulting
from the transformation of more than one base class constrctor, to
be deleted, so there would be an error only if it were used.</P>

<P><B>Notes from the April, 2013 meeting:</B></P>

<P>CWG agreed with the direction of defining such constructors as
deleted.</P>

<BR><BR><HR><A NAME="1715"></A><H4>1715.
  
Access and inherited constructor templates
</H4><B>Section: </B>12.9&#160; [class.inhctor]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2013-07-16<BR>




<P>Consider the following example:</P>

<PRE>
  template&lt;class T&gt; struct S {
  private:
    typedef int X;
    friend struct B;
  };

  struct B {
    template&lt;class T&gt; B(T, typename T::X);
  };

  struct D: B {
    using B::B;
  };

  S&lt;int&gt; s;
  B b(s, 2); //<SPAN style="font-family:Times;font-style:italic"> Okay, thanks to friendship.</SPAN>
  D d(s, 2); //<SPAN style="font-family:Times;font-style:italic"> Error: friendship is not inherited.</SPAN>
</PRE>

<P>My understanding is that the construction of <TT>d</TT> fails
because <TT>typename T::X</TT> expands to <TT>S&lt;int&gt;::X</TT> in this
case, and that is not accessible from <TT>D</TT>.</P>

<P>However, I'm not sure that makes sense from a usability perspective.
The user of <TT>D</TT> just wanted to be able to wrap class <TT>B</TT>, and
the fact that friendship was granted to <TT>B</TT> to enable its
constructor parameter seems like just an implementation detail
that <TT>D</TT> shouldn't have to cope with.</P>

<P>Would it perhaps be better to suspend access checking during the
instantiation of inheriting member function template declarations (not
definitions), since real access problems (e.g., the selection of a private
constructor) would presumably be revealed when doing the full
instantiation?</P>

<BR><BR><HR><A NAME="1736"></A><H4>1736.
  
Inheriting constructor templates in a local class
</H4><B>Section: </B>12.9&#160; [class.inhctor]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2013-08-13<BR>


<P>A local class cannot, according to 14.5.2 [temp.mem]
paragraph 2, have member templates.  Presumably, then, an example like
the following is ill-formed:</P>

<PRE>
  struct S {
    template&lt;class T&gt; S(T) {
      struct L: S {
        using S::S;
      };
    }
  }; 
</PRE>

<P>It is accepted by current implementations, however.  Does something need
to be said about this case in 12.9 [class.inhctor], either to
explicitly allow or forbid it, or is the restriction in
14.5.2 [temp.mem] sufficient?</P>

<BR><BR><HR><A NAME="1738"></A><H4>1738.
  
Explicit instantiation/specialization of inheriting constructor templates
</H4><B>Section: </B>12.9&#160; [class.inhctor]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2013-08-16<BR>


<P>It is not clear whether it is permitted to explicitly instantiate
or explicitly specialize specializations of inheriting constructor
templates.  Since inheriting constructors are considered to be implicitly
declared (12.9 [class.inhctor] paragraph 1), it might be inferred
that 14.7.2 [temp.explicit] paragraph 4 forbids their explicit
instantiation:</P>

<BLOCKQUOTE>

If the declaration of the explicit instantiation names an
implicitly-declared special member function (Clause
12 [special]), the program is ill-formed.

</BLOCKQUOTE>

<P>Similarly, an explicit specialization provides a definition for the
specialized member, and 12 [special] paragraph 1 forbids
defining an implicitly-declared special member function.</P>

<P>These inferences do not seem conclusive, however, so an explicit
statement in 12.9 [class.inhctor] would be helpful.</P>

<P>(See also <A HREF="
     cwg_active.html#1780">issue 1780</A>.)</P>

<BR><BR><HR><A NAME="1252"></A><H4>1252.
  
Overloading member function templates based on dependent return type
</H4><B>Section: </B>13.1&#160; [over.load]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-06<BR>




<P>The Standard does not allow overloading of member functions that
differ only in their return type (cf <TT>enable_if</TT>).</P>

<BR><BR><HR><A NAME="1278"></A><H4>1278.
  
Incorrect treatment of contrived object
</H4><B>Section: </B>13.3.1.1.1&#160; [over.call.func]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-27<BR>




<P>Footnote 127 of 13.3.1.1.1 [over.call.func] paragraph 3 reads,</P>

<BLOCKQUOTE>

An implied object argument must be contrived to correspond to the
implicit object parameter attributed to member functions during
overload resolution.  It is not used in the call to the selected
function.  Since the member functions all have the same implicit
object parameter, the contrived object will not be the cause to select
or reject a function.

</BLOCKQUOTE>

<P>It is not true that &#8220;the member functions all have the same
implicit object parameter.&#8221;  This statement does not take into
account member functions brought into the class by <I>using-declaration</I>s
or <I>cv-qualifier</I>s and <I>ref-qualifier</I>s on the non-static
member functions:</P>

<PRE>
    struct B
    {
      char f();         // B &amp;
    };

    struct D : B
    {
      using B::f;
      long f();         // D &amp;

      char g() const;   // D const &amp;
      long g();         // D &amp;

      char h() &amp;;       // D &amp;
      long h() &amp;&amp;;      // D &amp;&amp;
    };

    int main()
    {
      //<SPAN style="font-family:Times;font-style:italic"> </SPAN>D::f()<SPAN style="font-family:Times;font-style:italic"> has better match than </SPAN>B::f()<SPAN style="font-family:Times;font-style:italic"></SPAN>
      decltype(D().f()) *p1 = (long *)0;

      //<SPAN style="font-family:Times;font-style:italic"> </SPAN>D::g()<SPAN style="font-family:Times;font-style:italic"> has better match than </SPAN>D::g() const<SPAN style="font-family:Times;font-style:italic"></SPAN>
      decltype(D().g()) *p2 = (long *)0;

      //<SPAN style="font-family:Times;font-style:italic"> </SPAN>D::h() &amp;<SPAN style="font-family:Times;font-style:italic"> is not viable function</SPAN>
      //<SPAN style="font-family:Times;font-style:italic"> </SPAN>D::h() &amp;&amp;<SPAN style="font-family:Times;font-style:italic"> is viable function</SPAN>
      decltype(D().h()) *p3 = (long *)0;
    }
</PRE>

<P>The value category of a contrived object expression is not
specified by the rules and, probably, cannot be properly specified in
presence of <I>ref-qualifier</I>s, so the statement &#8220;the
contrived object will not be the cause to select or reject a
function&#8221; should be normative rather than informative:</P>

<PRE>
    struct X
    {
      static void f(double) {}
      void f(int) &amp; {}
      void f(int) &amp;&amp; {}
    };

    int main()
    {
      X::f(0); //<SPAN style="font-family:Times;font-style:italic"> ???</SPAN>
    }
</PRE>

<BR><BR><HR><A NAME="1687"></A><H4>1687.
  
Conversions of operands of built-in operators
</H4><B>Section: </B>13.3.1.2&#160; [over.match.oper]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-05-17<BR>




<P>Consider an example like:</P>

<PRE>
  struct Y {
    operator int*();
  };

  extern int *p;
  int *a = p + 100.0;   //<SPAN style="font-family:Times;font-style:italic"> #1</SPAN>
  int *b = Y() + 100.0; //<SPAN style="font-family:Times;font-style:italic"> #2</SPAN>
</PRE>

<P>#1 is ill-formed because it violates the requirement of
5.7 [expr.add] that the non-pointer operand have integral
or enumeration type.  It appears that #2 is well-formed, however,
because 13.3.1.2 [over.match.oper] paragraph 7 says,</P>

<BLOCKQUOTE>

If a built-in candidate is selected by overload resolution, the operands
are converted to the types of the corresponding parameters of the selected
operation function. Then the operator is treated as the corresponding
built-in operator and interpreted according to Clause
5 [expr].

</BLOCKQUOTE>

<P>In this case, the selected operation function is</P>

<PRE>
  int *operator+(int *, std::ptrdiff_t)
</PRE>

<P><TT>100.0</TT> is thus converted to <TT>std::ptrdiff_t</TT> before
reaching 5.7 [expr.add].</P>

<P>This problem could be addressed by restricting the conversion to
the class or enumeration operand rather than both operands.</P>

<BR><BR><HR><A NAME="455"></A><H4>455.
  
Partial ordering and non-deduced arguments
</H4><B>Section: </B>13.3.3&#160; [over.match.best]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Rani Sharoni
 &#160;&#160;&#160;

 <B>Date: </B>19 Jan 2004<BR>


<P>
It's not clear how overloading and partial ordering handle non-deduced pairs
of corresponding arguments. For example:</P>
<PRE>
template&lt;typename T&gt;
struct A { typedef char* type; };

template&lt;typename T&gt; char* f1(T, typename A&lt;T&gt;::type);  // #1
template&lt;typename T&gt; long* f1(T*, typename A&lt;T&gt;::type*); // #2

long* p1 = f1(p1, 0); // #3
</PRE>
<P>I thought that #3 is ambiguous but different compilers disagree on that.
Comeau C/C++ 4.3.3 (EDG 3.0.3) accepted the code, GCC 3.2 and BCC 5.5
selected #1 while VC7.1+ yields ambiguity.</P>

<P>I intuitively thought that the second pair should prevent overloading from
triggering partial ordering since both arguments are non-deduced and has
different types - (char*, char**). Just like in the following:</P>
<PRE>
template&lt;typename T&gt; char* f2(T, char*);   // #3
template&lt;typename T&gt; long* f2(T*, char**); // #4

long* p2 = f2(p2, 0); // #5
</PRE>
<P>In this case all the compilers I checked found #5 to be ambiguous.
The standard and DR <A HREF="
     cwg_defects.html#214">214</A> is not clear
about how partial ordering handle such
cases.</P>

<P>I think that overloading should not trigger partial ordering (in step
13.3.3 [over.match.best]/1/5) if some candidates have
non-deduced pairs with different
(specialized) types. In this stage the arguments are already adjusted so no
need to mention it (i.e. array to pointer). In case that one of the
arguments is non-deuced then partial ordering should only consider the type
from the specialization:</P>
<PRE>
template&lt;typename T&gt; struct B { typedef T type; };

template&lt;typename T&gt; char* f3(T, T);                   // #7
template&lt;typename T&gt; long* f3(T, typename B&lt;T&gt;::type); // #8

char* p3 = f3(p3, p3); // #9
</PRE>
<P>According to my reasoning #9 should yield ambiguity since second pair is (T,
long*). The second type (i.e. long*) was taken from the specialization
candidate of #8.
EDG and GCC accepted the code. VC and BCC found an ambiguity.</P>

<P><U>John Spicer:</U>
There may (or may not) be an issue concerning whether nondeduced
contexts are handled properly in the partial ordering rules.  In
general, I think nondeduced contexts work, but we should walk through
some examples to make sure we think they work properly.</P>

<P>Rani's description of the problem suggests that he believes that
partial ordering is done on the specialized types.  This is not
correct.  Partial ordering is done on the templates themselves,
independent of type information from the specialization.</P>

<P><B>Notes from October 2004 meeting:</B></P>

<P>John Spicer will investigate further to see if any action is
required.</P>

<P>(See also <A HREF="
     cwg_closed.html#885">issue 885</A>.)</P>



<BR><BR><HR><A NAME="1536"></A><H4>1536.
  
Overload resolution with temporary from initializer list
</H4><B>Section: </B>13.3.3.1.5&#160; [over.ics.list]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2012-08-14<BR>


<P>In determining the implicit conversion sequence for an initializer list
argument passed to a reference parameter, the intent is that a temporary
of the appropriate type will be created and bound to the reference, as
reflected in 13.3.3.1.5 [over.ics.list] paragraph 5:</P>

<BLOCKQUOTE>

Otherwise, if the parameter is a reference, see 13.3.3.1.4 [over.ics.ref].  [<I>Note:</I> The rules in this section will
apply for initializing the underlying temporary for the reference.
&#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>However, 13.3.3.1.4 [over.ics.ref] deals only with expression
arguments, not initializer lists:</P>

<BLOCKQUOTE>

<P>When a parameter of reference type binds directly (8.5.3 [dcl.init.ref]) to an argument expression, the implicit conversion
sequence is the identity conversion, unless the argument expression
has a type that is a derived class of the parameter type, in which
case the implicit conversion sequence is a derived-to-base Conversion
(13.3.3.1 [over.best.ics])... If the parameter binds directly to
the result of applying a conversion function to the argument
expression, the implicit conversion sequence is a user-defined
conversion sequence (13.3.3.1.2 [over.ics.user]), with the second
standard conversion sequence either an identity conversion or, if the
conversion function returns an entity of a type that is a derived
class of the parameter type, a derived-to-base Conversion.
</P>

<P>When a parameter of reference type is not bound directly to an
argument expression, the conversion sequence is the one required to
convert the argument expression to the underlying type of the
reference according to 13.3.3.1 [over.best.ics].  Conceptually,
this conversion sequence corresponds to copy-initializing a temporary
of the underlying type with the argument expression.  Any difference
in top-level cv-qualification is subsumed by the initialization itself
and does not constitute a conversion.
</P>

</BLOCKQUOTE>

<P>(Note in particular that the reference binding refers to
8.5.3 [dcl.init.ref], which also does not handle initializer
lists, and not to 8.5.4 [dcl.init.list].)</P>

<P>Either 13.3.3.1.4 [over.ics.ref] needs to be revised to
handle binding references to initializer list arguments or
13.3.3.1.5 [over.ics.list] paragraph 5 needs to be clearer on how
the expression specification is intended to be applied to
initializer lists.</P>



<BR><BR><HR><A NAME="1631"></A><H4>1631.
  
Incorrect overload resolution for single-element <I>initializer-list</I>
</H4><B>Section: </B>13.3.3.1.5&#160; [over.ics.list]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2013-03-03<BR>




<P>According to bullet 1 of 13.3.3.1.5 [over.ics.list] paragraph
6,</P>

<BLOCKQUOTE>

<P>Otherwise, if the parameter type is not a class:</P>

<UL><LI><P>if the initializer list has one element, the implicit conversion
sequence is the one required to convert the element to the parameter
type;</P></LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<P>This wording ignores the possibility that the element might be an
initializer list (as opposed to an expression with a type, as illustrated
in the example).  This oversight affects an example like:</P>

<PRE>
  struct A { int a[1]; };
  struct B { B(int); };
  void f(B, int);
  void f(int, A);

  int main() {
    f({0}, {{1}});
  }
</PRE>

<BR><BR><HR><A NAME="1589"></A><H4>1589.
  
Ambiguous ranking of list-initialization sequences
</H4><B>Section: </B>13.3.3.2&#160; [over.ics.rank]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2012-11-21<BR>




<P>The interpretation of the following example is unclear in the
current wording:</P>

<PRE>
   void f(long);
   void f(initializer_list&lt;int&gt;);
   int main() { f({1L});
</PRE>

<P>The problem is that a list-initialization sequence can also be
a standard conversion sequence, depending on the types of the elements
and the type of the parameter, so more than one bullet in the list
in 13.3.3.2 [over.ics.rank] paragraph 3 applies:</P>

<BLOCKQUOTE>

<P>Two implicit conversion sequences of the same form are
indistinguishable conversion sequences unless one of the following
rules applies:</P>

<UL><LI><P>Standard conversion sequence <TT>S1</TT> is a better
conversion sequence than standard conversion sequence <TT>S2</TT>
if</P></LI>

<UL><LI><P>...</P></LI>

<LI><P>the rank of <TT>S1</TT> is better than the rank of <TT>S2</TT>,
or <TT>S1</TT> and <TT>S2</TT> have the same rank and are
distinguishable by the rules in the paragraph below, or, if not
that,</P></LI>

<LI><P>...</P></LI>

</UL>

<LI><P>...</P></LI>

<LI>

<P>List-initialization sequence <TT>L1</TT> is a better conversion
sequence than list-initialization sequence <TT>L2</TT> if <TT>L1</TT>
converts to <TT>std::initializer_list&lt;X&gt;</TT> for some
<TT>X</TT> and <TT>L2</TT> does not.
</P></LI>

</UL>

</BLOCKQUOTE>

<P>These bullets give opposite results for the example above, and
there is implementation variance in which is selected.</P>

<P><B>Notes from the April, 2013 meeting:</B></P>

<P>CWG determined that the latter bullet should apply only if the
first one does not.</P>

<BR><BR><HR><A NAME="205"></A><H4>205.
  
Templates and static data members
</H4><B>Section: </B>14&#160; [temp]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>11 Feb 2000<BR>



<P>Static data members of template classes and of nested classes of
template classes are not themselves templates but receive much the
same treatment as template.  For instance,
14 [temp]
 paragraph 1 says that templates
are only "classes or functions" but implies that "a static data member
of a class template or of a class nested within a class template" is
defined using the <I>template-declaration</I> syntax.</P>

<P>There are many places in the clause, however, where static data
members of one sort or another are overlooked.  For instance,
14 [temp]
 paragraph 6 allows static data
members of class templates to be declared with the <TT>export</TT>
keyword.  I would expect that static data members of (non-template)
classes nested within class templates could also be exported, but they
are not mentioned here.</P>

<P>Paragraph 8, however, overlooks static data members altogether and
deals only with "templates" in defining the effect of the
<TT>export</TT> keyword; there is no description of the semantics of
defining a static data member of a template to be exported.</P>

<P>These are just two instances of a systematic problem.  The entire
clause needs to be examined to determine which statements about
"templates" apply to static data members, and which statements about
"static data members of class templates" also apply to static data
members of non-template classes nested within class templates.</P>

<P>(The question also applies to member functions of template classes;
see <A HREF="
     cwg_defects.html#217">issue 217</A>, where the phrase
"non-template function" in 8.3.6 [dcl.fct.default] paragraph 4
is apparently intended <I>not</I> to include non-template member
functions of template classes.  See also <A HREF="
     cwg_defects.html#108">issue 108</A>, which would benefit from understanding nested classes of
class templates as templates.  Also, see <A HREF="
     cwg_defects.html#249">issue 249</A>, in which the usage of the phrase "member function
template" is questioned.)</P>

<P><B>Notes from the 4/02 meeting:</B></P>

<P>Daveed Vandevoorde will propose appropriate terminology.</P>

<BR><BR><HR><A NAME="1444"></A><H4>1444.
  
Type adjustments of non-type template parameters
</H4><B>Section: </B>14.1&#160; [temp.param]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2012-01-15<BR>




<P>The type adjustment of template non-type parameters described in
14.1 [temp.param] paragraph 8 appears to be underspecified.  For
example, implementations vary in their treatment of</P>

<PRE>
  template&lt;typename T, T[T::size]&gt; struct A {};
  int dummy;
  A&lt;int, &amp;dummy&gt; a;
</PRE>

<P>and</P>

<PRE>
  template&lt;typename T, T[1]&gt; struct A;
  template&lt;typename T, T*&gt; struct A {};
  int dummy;
  A&lt;int, &amp;dummy&gt; a;
</PRE>

<P>See also <A HREF="
     cwg_active.html#1322">issue 1322</A>.</P>

<BR><BR><HR><A NAME="1635"></A><H4>1635.
  
How similar are template default arguments to function default arguments?
</H4><B>Section: </B>14.1&#160; [temp.param]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-03-06<BR>




<P>Default function arguments are instantiated only when needed.  Is
the same true of default template arguments?  For example, is the
following well-formed?</P>

<PRE>
  #include &lt;type_traits&gt;

  template&lt;class T&gt;
  struct X {
    template&lt;class U = typename T::type&gt;
    static void foo(int){}
    static void foo(...){}
  };

  int main(){
    X&lt;std::enable_if&lt;false&gt;&gt;::foo(0);
  }
</PRE>

<P>Also, is the effect on lookup the same?  E.g.,</P>

<PRE>
  struct S {
    template&lt;typename T = U&gt; void f();
    struct U {};
  };
</PRE>

<BR><BR><HR><A NAME="314"></A><H4>314.
  
<TT>template</TT> in base class specifier
</H4><B>Section: </B>14.2&#160; [temp.names]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Mark Mitchell
 &#160;&#160;&#160;

 <B>Date: </B>23 Aug 2001<BR>


<P>The EDG front-end accepts:</P>
<PRE>
template &lt;typename T&gt;
struct A {
  template &lt;typename U&gt;
  struct B {};
};

template &lt;typename T&gt;
struct C : public A&lt;T&gt;::template B&lt;T&gt; {
};
</PRE>
<P>It rejects this code if the base-specifier is spelled
<TT>A&lt;T&gt;::B&lt;T&gt;</TT>.</P>

<P>However, the grammar for a base-specifier does not allow the
<TT>template</TT> keyword.</P>

<P><B>Suggested resolution:</B></P>

It seems to me that a consistent approach to the solution that looks like
it will be adopted for <A HREF="
     cwg_defects.html#180">issue 180</A> (which deals
with the <TT>typename</TT> keyword in similar contexts) would be to
assume that <TT>B</TT> is a template if it is followed by a
"&lt;".  After all, an expression cannot appear in this context.

<P><B>Notes from the 4/02 meeting:</B></P>

<P>We agreed that <TT>template</TT> must be allowed in this context.
The syntax needs to be changed.  We also opened the related
<A HREF="
     cwg_active.html#343">issue 343</A>.</P>

<P><B>Additional note (August, 2010):</B></P>

<P>The same considerations apply to <I>mem-initializer-id</I>s, as noted
in <A HREF="
     cwg_closed.html#1019">issue 1019</A>.</P>

<BR><BR><HR><A NAME="1478"></A><H4>1478.
  
<TT>template</TT> keyword for dependent template template arguments
</H4><B>Section: </B>14.2&#160; [temp.names]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2012-03-10<BR>




<P>According to 14.2 [temp.names] paragraph 4,</P>

<BLOCKQUOTE>

When the name of a member template specialization appears after <TT>.</TT> or
<TT>-&gt;</TT> in a <I>postfix-expression</I> or after a
<I>nested-name-specifier</I> in a <I>qualified-id</I>, and the object
expression of the <I>postfix-expression</I> is type-dependent or the
<I>nested-name-specifier</I> in the <I>qualified-id</I> refers to a
dependent type, but the name is not a member of the current
instantiation (14.6.2.1 [temp.dep.type]), the member template
name must be prefixed by the keyword <TT>template</TT>.

</BLOCKQUOTE>

<P>In other words, the <TT>template</TT> keyword is only required when
forming a <I>template-id</I>.  However, current compilers reject an
example like:</P>

<PRE>
  template&lt;typename T, template&lt;typename&gt; class U = T::X&gt; struct A;
</PRE>

<P>and require the <TT>template</TT> keyword before <TT>X</TT>.
Should the rule be amended to require the <TT>template</TT> keyword in
cases like this?</P>

<BR><BR><HR><A NAME="1666"></A><H4>1666.
  
Address constant expressions
</H4><B>Section: </B>14.3.2&#160; [temp.arg.nontype]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-24<BR>




<P>The term &#8220;address constant expression&#8221; was removed by
paper N3652, but it is still referenced in the list of permissible
nontype template arguments in 14.3.2 [temp.arg.nontype] paragraph 1:</P>

<UL><LI><P>an address constant expression of
type <TT>std::nullptr_t</TT>.</P></LI>

</UL>

<BR><BR><HR><A NAME="1729"></A><H4>1729.
  
Matching declarations and definitions of variable templates
</H4><B>Section: </B>14.5&#160; [temp.decls]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Larisse Voufo
 &#160;&#160;&#160;

 <B>Date: </B>2013-08-05<BR>




<P>The relationship between declarations and definitions of variable
templates is not clear.  For example:</P>

<PRE>
  template&lt;typename T&gt; auto var0 = T();  //<SPAN style="font-family:Times;font-style:italic"> #1a.</SPAN>
  template&lt;typename T&gt; extern T var0;    //<SPAN style="font-family:Times;font-style:italic"> #1b.</SPAN>

  template&lt;typename T&gt; T var1;           //<SPAN style="font-family:Times;font-style:italic"> #2a.</SPAN>
  template&lt;typename T&gt; extern auto var1; //<SPAN style="font-family:Times;font-style:italic"> #2b.</SPAN>
  template&lt;typename T&gt; extern T var1;    //<SPAN style="font-family:Times;font-style:italic"> #2c.</SPAN>
  template&lt;typename T&gt; T var1;           //<SPAN style="font-family:Times;font-style:italic"> #2d.</SPAN>
</PRE>

<P>Questions:</P>

<OL><LI><P>When is a variable template declaration a definition and
when a non-defining declaration?</P></LI>

<LI><P>What declarations are valid?</P></LI>

<LI><P>Should <TT>auto</TT> declarations be allowed?</P></LI>

<LI><P>To what extent, if any, do these involve type matching?</P></LI>

<LI><P>How are types matched, especially in the presence of
<TT>auto</TT>?</P></LI>

</OL>

<BR><BR><HR><A NAME="1730"></A><H4>1730.
  
Can a variable template have an unnamed type?
</H4><B>Section: </B>14.5&#160; [temp.decls]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Larisse Voufo
 &#160;&#160;&#160;

 <B>Date: </B>2013-08-05<BR>




<P>Is it permitted for a variable template to have an unnamed
type?</P>

<BR><BR><HR><A NAME="1432"></A><H4>1432.
  
Newly-ambiguous variadic template expansions
</H4><B>Section: </B>14.5.3&#160; [temp.variadic]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2011-12-17<BR>


<P>With the new core rules in regard to variadic pack expansions
the library specification of the traits template
<TT>common_type</TT> is now broken, the reason is that it is
defined as a series of specializations of the primary template</P>

<PRE>
    template &lt;class ...T&gt;
    struct common_type;
</PRE>

<P>The broken one is this pair:</P>

<PRE>
  template &lt;class T, class U&gt;
  struct common_type&lt;T, U&gt; {
   typedef decltype(true ? declval&lt;T&gt;() : declval&lt;U&gt;()) type;
  };

  template &lt;class T, class U, class... V&gt;
  struct common_type&lt;T, U, V...&gt; {
   typedef typename common_type&lt;typename common_type&lt;T, U&gt;::type, V...&gt;::type type;
  };
</PRE>

<P>With the new rules both specializations would now be ambiguous
for an instantiation like <TT>common_type&lt;X, Y&gt;</TT>.</P>

<P>(See also <A HREF="
     cwg_active.html#1395">issue 1395</A>.)</P>

<P><B>Notes from the October, 2012 meeting:</B></P>

<P>It is possible that 14.5.5.2 [temp.class.order] may resolve this
problem.</P>

<BR><BR><HR><A NAME="1545"></A><H4>1545.
  
<TT>friend</TT> function templates defined in class templates
</H4><B>Section: </B>14.5.4&#160; [temp.friend]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2012-08-25<BR>




<P>The status of an example like the following is not clear:</P>

<PRE>
   template&lt;class&gt; struct x {
     template&lt;class T&gt;
     friend bool operator==(x&lt;T&gt;, x&lt;T&gt;) { return false; }
  };

  int main() {
    x&lt;int&gt; x1;
    x&lt;double&gt; x2;
    x1 == x1;
    x2 == x2;
  }
</PRE>

<P>Such a <TT>friend</TT> definition is permitted by
14.5.4 [temp.friend] paragraph 2:</P>

<BLOCKQUOTE>

A friend function template may be defined within a class or class
template...

</BLOCKQUOTE>

<P>Paragraph 4 appears to be related, but deals only with friend functions,
not friend function templates:</P>

<BLOCKQUOTE>

When a function is defined in a friend function declaration in a class
template, the function is instantiated when the function is
odr-used. The same restrictions on multiple declarations and
definitions that apply to non-template function declarations and
definitions also apply to these implicit definitions.

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1315"></A><H4>1315.
  
Restrictions on non-type template arguments in partial specializations
</H4><B>Section: </B>14.5.5&#160; [temp.class.spec]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2011-05-12<BR>




<P>The rationale for the restriction in 14.5.5 [temp.class.spec]
paragraph 8, first bullet is not clear:</P>

<UL><LI><P>A partially specialized non-type argument expression shall
not involve a template parameter of the partial specialization except
when the argument expression is a simple
<I>identifier</I>. [<I>Example:</I></P></LI>

<PRE>
  template &lt;int I, int J&gt; struct A {};
  template &lt;int I&gt; struct A&lt;I+5, I*2&gt; {}; //<SPAN style="font-family:Times;font-style:italic"> error</SPAN>
  template &lt;int I, int J&gt; struct B {};
  template &lt;int I&gt; struct B&lt;I, I&gt; {};     //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
</PRE>

<P>&#8212;<I>end example</I>]</P>

</UL>

<P>In the example, it's clear that <TT>I</TT> is non-deducible, but
this rule prevents plausible uses like:</P>

<PRE>
  template &lt;int I, int J&gt; struct A {};
  template &lt;int I&gt; struct A&lt;I, I*2&gt; {};
</PRE>



<BR><BR><HR><A NAME="1647"></A><H4>1647.
  
Type agreement of non-type template arguments in partial specializations
</H4><B>Section: </B>14.5.5&#160; [temp.class.spec]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-04<BR>


<P>The Standard appears to be silent on whether the types of
non-type template arguments in a partial specialization must be
the same as those of the primary template or whether conversions
are permitted.  For example,</P>

<PRE>
  template&lt;char...&gt; struct char_values {};
  template&lt;int C1, char C3&gt;
  struct char_values&lt;C1, 12, C3&gt; {
    static const unsigned value = 1;
  };
  int check0[char_values&lt;1, 12, 3&gt;::value == 1? 1 : -1]; 
</PRE>

<P>The closest the current wording comes to dealing with this
question is 14.5.5 [temp.class.spec] paragraph 8 bullet 1:</P>

<UL><LI><P>A partially specialized non-type argument expression shall
not involve a template parameter of the partial
specialization except when the argument expression is a
simple <I>identifier</I>.</P></LI>

</UL>

<P>In this example, one might think of the first template argument
in the partial specialization as <TT>(char)C1</TT>, which would
violate the requirement, but that reasoning is tenuous.</P>

<P>It would be reasonable to require the types to match in
cases like this.  If this kind of usage is allowed it could
get messy if the primary template were <TT>int...</TT> and
the partial specialization had a parameter that
was <TT>char</TT> because not all of the possible values
from the primary template could be represented in the
parameter of the partial specialization.  A similar issue
exists if the primary template takes <TT>signed char</TT>
and the partial specialization takes <TT>unsigned
int</TT>.</P>

<P>There is implementation variance in the treatment of this
example.</P>

<BR><BR><HR><A NAME="549"></A><H4>549.
  
Non-deducible parameters in partial specializations
</H4><B>Section: </B>14.5.5.1&#160; [temp.class.spec.match]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Martin Sebor
 &#160;&#160;&#160;

 <B>Date: </B>18 November 2005<BR>


<P>In the following example, the template parameter in the partial
specialization is non-deducible:</P>

<PRE>
    template &lt;class T&gt; struct A { typedef T U; };
    template &lt;class T&gt; struct C { };
    template &lt;class T&gt; struct C&lt;typename A&lt;T&gt;::U&gt; { };
</PRE>

<P>Several compilers issue errors for this case, but there appears
to be nothing in the Standard that would make this ill-formed; it
simply seems that the partial specialization will never be matched,
so the primary template will be used for all specializations.
Should it be ill-formed?</P>

<P>(See also <A HREF="
     cwg_defects.html#1246">issue 1246</A>.)</P>

<P><B>Notes from the April, 2006 meeting:</B></P>

<P>It was noted that there are similar issues for constructors and
conversion operators with non-deducible parameters, and that they
should probably be dealt with similarly.</P>

<BR><BR><HR><A NAME="1446"></A><H4>1446.
  
Member function with no <I>ref-qualifier</I> and non-member function with rvalue reference
</H4><B>Section: </B>14.5.6.2&#160; [temp.func.order]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2012-02-07<BR>


<P>A member function with no <I>ref-qualifier</I> can be called for a
class prvalue, as can a non-member function whose first parameter is an
rvalue reference to that class type.  However, 14.5.6.2 [temp.func.order]
does not handle this case.</P>

<BR><BR><HR><A NAME="1286"></A><H4>1286.
  
Equivalence of alias templates
</H4><B>Section: </B>14.5.7&#160; [temp.alias]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Gabriel Dos Reis
 &#160;&#160;&#160;

 <B>Date: </B>2011-04-03<BR>




<P><A HREF="
     cwg_defects.html#1244">Issue 1244</A> was resolved by changing the
example in 14.4 [temp.type] paragraph 1 from</P>

<PRE>
  template&lt;template&lt;class&gt; class TT&gt; struct X { };
  template&lt;class&gt; struct Y { };
  template&lt;class T&gt; using Z = Y&lt;T&gt;;
  X&lt;Y&gt; y;
  X&lt;Z&gt; z;
</PRE>

<P>to</P>

<PRE>
  template&lt;class T&gt; struct X { };
  template&lt;class&gt; struct Y { };
  template&lt;class T&gt; using Z = Y&lt;T&gt;;
  X&lt;Y&lt;int&gt; &gt; y;
  X&lt;Z&lt;int&gt; &gt; z;
</PRE>

<P>In fact, the original intent was that the example should have been
correct as written; however, the normative wording to make it so was
missing.  The current wording of 14.5.7 [temp.alias] deals
only with the equivalence of a specialization of an alias template
with the <I>type-id</I> after substitution.  Wording needs to be added
specifying under what circumstances an alias template itself is
equivalent to a class template.</P>

<P><B>Proposed resolution (September, 2012):</B></P>

<OL><LI><P>Add the following as a new paragraph following 14.5.7 [temp.alias] paragraph 2:</P></LI>

<BLOCKQUOTE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">When the <I>type-id</I> in the declaration of alias template (call
it <TT>A</TT>) consists of a <I>simple-template-id</I> in which the
<I>template-argument-list</I> consists of a list of <I>identifier</I>s
naming each <I>template-parameter</I> of <TT>A</TT> exactly once in
the same order in which they appear in <TT>A</TT>'s
<I>template-parameter-list</I>, the alias template is equivalent to
the template named in the <I>simple-template-id</I> (call it
<TT>T</TT>) if <TT>A</TT> and <TT>T</TT> have the same number of
<I>template-parameter</I>s. [<I>Footnote:</I> This rule is transitive:
if an alias template <TT>A</TT> is equivalent to another alias
template <TT>B</TT> that is equivalent to a class template <TT>C</TT>,
then <TT>A</TT> is also equivalent to <TT>C</TT>, and <TT>A</TT> and
<TT>B</TT> are also equivalent to each other. &#8212;<I>end
footnote</I>] [<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  template&lt;typename T, U = T&gt; struct A;

  template&lt;typename V, typename W&gt;
    using B = A&lt;V, W&gt;;                //<SPAN style="font-family:Times;font-style:italic"> equivalent to </SPAN>A

  template&lt;typename V, typename W&gt;
    using C = A&lt;V&gt;;                   //<SPAN style="font-family:Times;font-style:italic"> not equivalent to </SPAN>A<SPAN style="font-family:Times;font-style:italic">:</SPAN>
                                      //<SPAN style="font-family:Times;font-style:italic"> not all parameters used</SPAN>

  template&lt;typename V&gt;
    using D = A&lt;V&gt;;                   //<SPAN style="font-family:Times;font-style:italic"> not equivalent to </SPAN>A<SPAN style="font-family:Times;font-style:italic">:</SPAN>
                                      //<SPAN style="font-family:Times;font-style:italic"> different number of parameters</SPAN>

  template&lt;typename V, typename W&gt;
    using E = A&lt;W, V&gt;;                //<SPAN style="font-family:Times;font-style:italic"> not equivalent to </SPAN>A<SPAN style="font-family:Times;font-style:italic">:</SPAN>
                                      //<SPAN style="font-family:Times;font-style:italic"> template-arguments in wrong order</SPAN>

  template&lt;typename V, typename W = int&gt;
    using F = A&lt;V, W&gt;;                //<SPAN style="font-family:Times;font-style:italic"> equivalent to </SPAN>A<SPAN style="font-family:Times;font-style:italic">:</SPAN>
                                      //<SPAN style="font-family:Times;font-style:italic"> default arguments not considered</SPAN>

  template&lt;typename V, typename W&gt;
    using G = A&lt;V, W&gt;;                //<SPAN style="font-family:Times;font-style:italic"> equivalent to </SPAN>A<SPAN style="font-family:Times;font-style:italic"> and </SPAN>B

  template&lt;typename V, typename W&gt;
    using H = E&lt;V, W&gt;;                //<SPAN style="font-family:Times;font-style:italic"> equivalent to </SPAN>E

  template&lt;typename V, typename W&gt;
    using I = A&lt;V, typename W::type&gt;; //<SPAN style="font-family:Times;font-style:italic"> not equivalent to </SPAN>A<SPAN style="font-family:Times;font-style:italic">:</SPAN>
                                      //<SPAN style="font-family:Times;font-style:italic"> argument not identifier</SPAN></SPAN>

</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end example</I>]</SPAN></P>

</BLOCKQUOTE>

<LI><P>Change 14.4 [temp.type] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

<P>Two <I>template-id</I>s refer to the same class or function if</P>

<UL><LI><P>...</P></LI>

<LI><P>their corresponding template <I>template-argument</I>s refer to
the same <SPAN style="font-weight:bold;background-color:#A0FFA0">or equivalent (14.5.7 [temp.alias])</SPAN>
template<SPAN style="font-weight:bold;background-color:#A0FFA0">s</SPAN>.
</P></LI>

</UL>

<P>[<I>Example:</I></P>

<P>...declares <TT>x2</TT> and <TT>x3</TT> to be of the same type. Their type differs from the types of <TT>x1</TT> and <TT>x4</TT>.</P>

<PRE>
  template&lt;<SPAN style="text-decoration:line-through;background-color:#FFA0A0">class T</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">template&lt;class&gt; class TT</SPAN>&gt; struct X { };
  template&lt;class&gt; struct Y { };
  template&lt;class T&gt; using Z = Y&lt;T&gt;;
  X&lt;<SPAN style="text-decoration:line-through;background-color:#FFA0A0">Y&lt;int&gt;</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">Y</SPAN>&gt; y;
  X&lt;<SPAN style="text-decoration:line-through;background-color:#FFA0A0">Z&lt;int&gt;</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">Z</SPAN>&gt; z;
</PRE>

<P>declares <TT>y</TT> and <TT>z</TT> to be of the same type.
&#8212;<I>end example</I>]</P>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1349"></A><H4>1349.
  
Consistency of alias template redeclarations
</H4><B>Section: </B>14.5.7&#160; [temp.alias]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2011-08-16<BR>




<P>There appears to be no requirement that a redeclaration of an alias
template must be equivalent to the earlier one. An <I>alias-declaration</I>
is not a definition (3.1 [basic.def] paragraph 2), so presumably
an alias template declaration is also not a definition and thus the ODR
does not apply.</P>

<BR><BR><HR><A NAME="1430"></A><H4>1430.
  
Pack expansion into fixed alias template parameter list
</H4><B>Section: </B>14.5.7&#160; [temp.alias]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2011-12-13<BR>




<P>Originally, a pack expansion could not expand into a
fixed-length template parameter list, but this was changed in
N2555.  This works fine for most templates, but causes issues
with alias templates.</P>

<P>In most cases, an alias template is transparent; when it's
used in a template we can just substitute in the dependent
template arguments.  But this doesn't work if the
<I>template-id</I> uses a pack expansion for non-variadic
parameters.  For example:</P>

<PRE>
    template&lt;class T, class U, class V&gt;
    struct S {};

    template&lt;class T, class V&gt;
    using A = S&lt;T, int, V&gt;;

    template&lt;class... Ts&gt;
    void foo(A&lt;Ts...&gt;);
</PRE>

<P>There is no way to express <TT>A&lt;Ts...&gt;</TT> in terms of
<TT>S</TT>, so we need to hold onto the <TT>A</TT> until we have
the <TT>Ts</TT> to substitute in, and therefore it needs to be
handled in mangling.</P>

<P>Currently, EDG and Clang reject this testcase, complaining
about too few template arguments for A.  G++ did as well, but I
thought that was a bug.  However, on the ABI list John Spicer
argued that it should be rejected.</P>

<P>(See also <A HREF="
     cwg_active.html#1558">issue 1558</A>.)</P>

<P><B>Notes from the October, 2012 meeting:</B></P>

<P>The consensus of CWG was that this usage should be prohibited,
disallowing use of an alias template when a dependent argument can't
simply be substituted directly into the <I>type-id</I>.</P>

<P><B>Additional note, April, 2013:</B></P>

<P>For another example, consider:</P>

<PRE>
  template&lt;class... x&gt; class list{};
  template&lt;class a, class... b&gt; using tail=list&lt;b...&gt;;
  template &lt;class...T&gt; void f(tail&lt;T...&gt;);

  int main() {
    f&lt;int,int&gt;({});
  }
</PRE>

<P>There is implementation variance in the handling of this
example. </P>

<BR><BR><HR><A NAME="1554"></A><H4>1554.
  
Access and alias templates
</H4><B>Section: </B>14.5.7&#160; [temp.alias]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2012-09-17<BR>




<P>The interaction of alias templates and access control is not clear
from the current wording of 14.5.7 [temp.alias].  For
example:</P>

<PRE>
  template &lt;class T&gt; using foo = typename T::foo;

  class B {
    typedef int foo;
    friend struct C;
  };

  struct C {
    foo&lt;B&gt; f;    //<SPAN style="font-family:Times;font-style:italic"> Well-formed?</SPAN>
  };
</PRE>

<P>Is the substitution of <TT>B::foo</TT> for <TT>foo&lt;B&gt;</TT>
done in the context of the befriended class <TT>C</TT>, making the
reference well-formed, or is the access determined independently of
the context in which the alias template specialization appears?</P>

<P>If the answer to this question is that the access is determined
independently from the context, care must be taken to ensure that an
access failure is still considered to be &#8220;in the immediate
context of the function type&#8221; (14.8.2 [temp.deduct]
paragraph 8) so that it results in a deduction failure rather than
a hard error.</P>

<P><B>Notes from the October, 2012 meeting:</B></P>

<P>The consensus of CWG was that instantiation (lookup and access)
for alias templates should be as for other templates, in the definition
context rather than in the context where they are used.  They should
still be expanded immediately, however.</P>

<BR><BR><HR><A NAME="1558"></A><H4>1558.
  
Unused arguments in alias template specializations
</H4><B>Section: </B>14.5.7&#160; [temp.alias]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2012-09-19<BR>




<P>The treatment of unused arguments in an alias template specialization
is not specified by the current wording of 14.5.7 [temp.alias].
For example:</P>

<PRE>
  #include &lt;iostream&gt;

  template &lt;class T, class...&gt;
    using first_of = T;

  template &lt;class T&gt;
    first_of&lt;void, typename T::type&gt; f(int)
      { std::cout &lt;&lt; "1\n"; }

  template &lt;class T&gt;
    void f(...)
      { std::cout &lt;&lt; "2\n"; }

  struct X { typedef void type; };

  int main() {
    f&lt;X&gt;(0);
    f&lt;int&gt;(0);
  }
</PRE>

<P>Is the reference to <TT>first_of&lt;void, T::type&gt;</TT> with
<TT>T</TT> being <TT>int</TT> equivalent to simply <TT>void</TT>, or
is it a substitution failure?</P>

<P>(See also issues <A HREF="
     cwg_active.html#1430">1430</A>,
<A HREF="
     cwg_closed.html#1520">1520</A>, and <A HREF="
     cwg_active.html#1554">1554</A>.)</P>

<P><B>Notes from the October, 2012 meeting:</B></P>

<P>The consensus of CWG was to treat this case as substitution
failure.</P>

<BR><BR><HR><A NAME="560"></A><H4>560.
  
Use of the <TT>typename</TT> keyword in return types
</H4><B>Section: </B>14.6&#160; [temp.res]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Greg Comeau
 &#160;&#160;&#160;

 <B>Date: </B>11 February 2006<BR>


<P>Consider the following example:</P>

<PRE>
    template &lt;class T&gt; struct Outer {
        struct Inner {
            Inner* self();
        };
    };
    template &lt;class T&gt; Outer&lt;T&gt;::Inner*
        Outer&lt;T&gt;::Inner::self() { return this; }
</PRE>

<P>According to 14.6 [temp.res] paragraph 3 (before the
salient wording was inadvertently removed, see
<A HREF="
     cwg_defects.html#559">issue 559</A>),</P>

<BLOCKQUOTE>

A <I>qualified-id</I> that refers to a type and in which the
<I>nested-name-specifier</I> depends on a <I>template-parameter</I>
(14.6.2 [temp.dep]) but does not refer to a member of the
current instantiation (14.6.2.1 [temp.dep.type]) shall be
prefixed by the keyword <TT>typename</TT> to indicate that
the <I>qualified-id</I> denotes a type, forming
a <I>typename-specifier</I>.

</BLOCKQUOTE>

<P>Because <TT>Outer&lt;T&gt;::Inner</TT> is a member of the current
instantiation, the Standard does not currently require that it be
prefixed with <TT>typename</TT> when it is used in the return type of
the definition of the <TT>self()</TT> member function.  However, it is
difficult to parse this definition correctly without knowing that the
return type is, in fact, a type, which is what the <TT>typename</TT>
keyword is for.  Should the Standard be changed to require
<TT>typename</TT> in such contexts?</P>



<BR><BR><HR><A NAME="1271"></A><H4>1271.
  
Imprecise wording regarding dependent types
</H4><B>Section: </B>14.6&#160; [temp.res]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-24<BR>


<P>According to 14.6 [temp.res] paragraph 3,</P>

<BLOCKQUOTE>

When a <I>qualified-id</I> is intended to refer to a type that is not
a member of the current instantiation (14.6.2.1 [temp.dep.type])
and its <I>nested-name-specifier</I> refers to a dependent type, it
shall be prefixed by the keyword <TT>typename</TT>, forming a
<I>typename-specifier</I>.  If the <I>qualified-id</I> in a
<I>typename-specifier</I> does not denote a type, the program is ill-
formed.

</BLOCKQUOTE>

<P>The intent of the programmer cannot form the basis for a compiler
determining whether to issue a diagnostic or not.</P>

<U>Suggested resolution:</U>

<BLOCKQUOTE>

<P>Let <TT>N</TT> be a <I>qualified-id</I> with a
<I>nested-name-specifier</I> that denotes a dependent type.  If
<TT>N</TT> is not prefixed by the keyword <TT>typename</TT>, <TT>N</TT>
shall refer to a member of the current instantiation or it shall not
refer to a type.</P>

<UL><I>typename-specifier:</I>
<UL><TT>typename</TT> <I>nested-name-specifier identifier</I><BR>
<TT>typename</TT> <I>nested-name-specifier </I><TT>template</TT><I><SUB>opt</SUB> simple-template-id</I></UL>
</UL>

<P>If the <I>qualified-id</I> in a <I>typename-specifier</I> does not
denote a type, the program is ill-formed.</P>

</BLOCKQUOTE>

<P>(See also issues <A HREF="
     cwg_defects.html#590">590</A> and
<A HREF="
     cwg_active.html#591">591</A>.)</P>

<BR><BR><HR><A NAME="591"></A><H4>591.
  
When a dependent base class is the current instantiation
</H4><B>Section: </B>14.6.2&#160; [temp.dep]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>24 August 2006<BR>




<P>Is the following example well-formed?</P>

<PRE>
    template&lt;class T&gt; struct A {
         typedef int M;
         struct B {
             typedef void M;
             struct C;
         };
    };

    template&lt;class T&gt; struct A&lt;T&gt;::B::C : A&lt;T&gt; {
         M  // A&lt;T&gt;::M or A&lt;T&gt;::B::M?
             p[2];
    };
</PRE>

<P>14.6.2 [temp.dep] paragraph 3 says the use
of <TT>M</TT> should refer to <TT>A&lt;T&gt;::B::M</TT> because
the base class <TT>A&lt;T&gt;</TT> is not searched because it's
dependent.  But in this case <TT>A&lt;T&gt;</TT> is also the
current instantiation (14.6.2.1 [temp.dep.type]) so it
seems like it should be searched.
</P>

<P><B>Notes from the August, 2011 meeting:</B></P>

<P>The recent changes to the handling of the current instantiation
may have sufficiently addressed this issue.  </P>

<P><B>Additional note (September, 2012):</B></P>

<P>See also <A HREF="
     cwg_closed.html#1526">issue 1526</A> for additional
analysis demonstrating that this issue is still current despite the
changes to the description of the current instantiation.  The status
has consequently been changed back to "open"  for further consideration.</P>

<BR><BR><HR><A NAME="1292"></A><H4>1292.
  
Dependent calls with <I>braced-init-list</I>s containing a pack expansion
</H4><B>Section: </B>14.6.2&#160; [temp.dep]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>2011-04-10<BR>


<P>The discussion of <A HREF="
     cwg_defects.html#1233">issue 1233</A> revealed
that the dependency of function calls involving a
<I>braced-init-list</I> containing a pack expansion is not adequately
addressed by the existing wording.</P>

<BR><BR><HR><A NAME="1309"></A><H4>1309.
  
Incorrect note regarding lookup of a member of the current instantiation
</H4><B>Section: </B>14.6.2.1&#160; [temp.dep.type]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2011-05-05<BR>




<P>The note in 14.6.2.1 [temp.dep.type] paragraph 7 reads,</P>

<BLOCKQUOTE>

[<I>Note:</I> the result of name lookup differs only when the member
of the current instantiation was found in a non-dependent base class
of the current instantiation and a member with the same name is also
introduced by the substitution for a dependent base class of the
current instantiation.  &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>However, this is not correct.  Consider the following example:</P>

<PRE>
  struct Y { int X; };

  template&lt;typename T&gt;
  struct A : Y {
   enum B : int;
   void f() { A::X; } //<SPAN style="font-family:Times;font-style:italic"> finds </SPAN>Y::X<SPAN style="font-family:Times;font-style:italic"> here!</SPAN>
  };

  template&lt;typename T&gt;
  enum A&lt;T&gt;::B : int {
   X //<SPAN style="font-family:Times;font-style:italic"> introduces member </SPAN>A::X<SPAN style="font-family:Times;font-style:italic"> into </SPAN>A&lt;T&gt;<SPAN style="font-family:Times;font-style:italic">!</SPAN>
  };

  void g() { A&lt;int&gt; a; a.f(); }
</PRE>

<P><TT>A::X</TT> is a member of the current instantiation, so
paragraph 7 requires it to be looked up again when instantiating and
to give a diagnostic if the lookup differs from the lookup in the
definition context. The note incorrectly indicates that this can only
happen if the conflicting name was introduced by a dependent base
class.</P>

<P><B>Proposed resolution (August, 2011):</B></P>

<P>Change 14.6.2.1 [temp.dep.type] paragraph 7 as follows:</P>

<BLOCKQUOTE>

<P>...If the result of this lookup differs from the result of name
lookup in the template definition context, name lookup is
ambiguous. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">[<I>Note:</I> the result of name lookup differs only
when the member of the current instantiation was found in a
non-dependent base class of the current instantiation and a member
with the same name is also introduced by the substitution for a
dependent base class of the current instantiation. &#8212;<I>end
note</I>]</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  struct A {
    int m;
  };

  struct B {
    int m;
  };

  template&lt;typename T&gt;
  struct C : A, T {
    int f() { return this-&gt;m; } //<SPAN style="font-family:Times;font-style:italic"> finds </SPAN>A::m<SPAN style="font-family:Times;font-style:italic"> in the template definition context</SPAN>
  };

  int g(C&lt;B&gt; cb) {
    return cb.f();              //<SPAN style="font-family:Times;font-style:italic"> error: finds both </SPAN>A::m<SPAN style="font-family:Times;font-style:italic"> and </SPAN>B::m<SPAN style="font-family:Times;font-style:italic"> in the template instantiation context</SPAN>
  }</SPAN>
</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end example</I>]</SPAN></P>

</BLOCKQUOTE>

<P><B>Notes from the December, 2011 teleconference:</B></P>

<P>Changes to the exposition were suggested and the issue returned to
"drafting" status.</P>

<BR><BR><HR><A NAME="1390"></A><H4>1390.
  
Dependency of alias template specializations
</H4><B>Section: </B>14.6.2.1&#160; [temp.dep.type]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2011-09-04<BR>




<P>According to 14.6.2.1 [temp.dep.type] paragraph 8, a type
is dependent (among other things) if it is</P>

<UL><LI><P>a <I>simple-template-id</I> in which either the
template name is a template parameter or any of the template
arguments is a dependent type or an expression that is
type-dependent or value-dependent</P></LI></UL>

<P>This applies to alias template specializations, even if the
resulting type does not depend on the template argument:</P>

<PRE>
    struct B { typedef int type; };
    template&lt;typename&gt; using foo = B;
    template&lt;typename T&gt; void f() {
      foo&lt;T&gt;::type * x;  //<SPAN style="font-family:Times;font-style:italic">error: </SPAN><TT>typename</TT><SPAN style="font-family:Times;font-style:italic"> required</SPAN>
    }
</PRE>

<P>Is a change to the rules for cases like this warranted?</P>

<P><B>Notes from the October, 2012 meeting:</B></P>

<P>CWG agreed that no <TT>typename</TT> should be required in this
case.  In some ways, an alias template specialization is like the current
instantiation and can be known at template definition time.</P>

<BR><BR><HR><A NAME="1524"></A><H4>1524.
  
Incompletely-defined class template base
</H4><B>Section: </B>14.6.2.1&#160; [temp.dep.type]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2012-07-17<BR>




<P>The correct handling of an example like the following is unclear:</P>

<PRE>
  template&lt;typename T&gt; struct A {
    struct B: A { };
  };
</PRE>

<P>A type used as a base must be complete (10 [class.derived]
paragraph 2).  The fact that the base class in this example is the
current instantiation could be interpreted as indicating that it
should be available for lookup, and thus the normal rule should apply,
as members declared after the nested class would not be visible.</P>

<P>On the other hand, 14.6.2 [temp.dep] paragraph 3
says,</P>

<BLOCKQUOTE>

In the definition of a class or class template, if a base class
depends on a <I>template-parameter</I>, the base class scope is not
examined during unqualified name lookup either at the point of
definition of the class template or member or during an instantiation
of the class template or member.

</BLOCKQUOTE>

<P>This wording refers not to a dependent type, which would permit
lookup in the current instantiation, but simply to a type that
&#8220;depends on a <I>template-parameter</I>,&#8221; and the current
instantiation is such a type.</P>

<P>Implementations vary on the handling of this example.</P>

<P>(See also <A HREF="
     cwg_closed.html#1526">issue 1526</A> for another case
related to the distinction between a &#8220;dependent type&#8221; and
a &#8220;type that depends on a <I>template-parameter</I>.&#8221;)</P>

<P><B>Notes from the October, 2012 meeting:</B></P>

<P>CWG determined that the example should be ill-formed.</P>

<BR><BR><HR><A NAME="1737"></A><H4>1737.
  
Type dependence of call to a member of the current instantiation
</H4><B>Section: </B>14.6.2.1&#160; [temp.dep.type]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-08-14<BR>






<P>Since we don't deduce the return type of a function temploid until it is
instantiated, it seems that a call to such a function as a member of the
current instantiation must have a dependent type, but
14.6.2.2 [temp.dep.expr] doesn't appear to say that.  For example:</P>

<PRE>
   template&lt;typename T&gt; struct X { typedef int type; };
   template&lt;typename T&gt; struct S {
     auto f() { return 0; }
     void g() {
       X&lt;decltype(f())&gt;::type x; //<SPAN style="font-family:Times;font-style:italic"> </SPAN>typename<SPAN style="font-family:Times;font-style:italic"> presumably needed here</SPAN>
     }
   }
</PRE>

<P>Presumably there should be a bullet in 14.6.2.1 [temp.dep.type]
paragraph 8 for this case.</P>

<BR><BR><HR><A NAME="2"></A><H4>2.
  
How can dependent names be used in member declarations that appear outside of the class template definition?
</H4><B>Section: </B>14.6.4&#160; [temp.dep.res]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>unknown
 &#160;&#160;&#160;

 <B>Date: </B>unknown<BR>





<PRE>
    template &lt;class T&gt; class Foo {
    
       public:
       typedef int Bar;
       Bar f();
    };
    template &lt;class T&gt; typename Foo&lt;T&gt;::Bar Foo&lt;T&gt;::f() { return 1;}
                       --------------------
</PRE>
In the class template definition, the declaration of the member function
is interpreted as:
<PRE>
   int Foo&lt;T&gt;::f();
</PRE>
In the definition of the member function that appears outside of the class
template, the return type is not known until the member function
is instantiated.
Must the return type of the member function be known when this out-of-line
definition is seen (in which case the definition above is ill-formed)?
Or is it OK to wait until the member function is instantiated to see if
the type of the return type matches the return type in the class template
definition (in which case the definition above is well-formed)?
    
<P><B>Suggested resolution:</B> (John Spicer)</P>
    
<P>My opinion (which I think matches several posted on the reflector recently)
is that the out-of-class definition must match the
declaration in the template. 
In your example they do match, so it is well formed.</P>
    
<P>I've added some additional cases that illustrate cases that I think
either are allowed or should be allowed, and some cases that I don't think
are allowed.</P>
<PRE>
    template &lt;class T&gt; class A { typedef int X; };
    
    
    template &lt;class T&gt; class Foo {
     public:
       typedef int Bar;
       typedef typename A&lt;T&gt;::X X;
       Bar f();
       Bar g1();
       int g2();
       X h();
       X i();
       int j();
     };
    
     // Declarations that are okay
     template &lt;class T&gt; typename Foo&lt;T&gt;::Bar Foo&lt;T&gt;::f()
                                                     { return 1;}
     template &lt;class T&gt; typename Foo&lt;T&gt;::Bar Foo&lt;T&gt;::g1()
                                                     { return 1;}
     template &lt;class T&gt; int Foo&lt;T&gt;::g2() { return 1;}
     template &lt;class T&gt; typename Foo&lt;T&gt;::X Foo&lt;T&gt;::h() { return 1;}
    
     // Declarations that are not okay
     template &lt;class T&gt; int Foo&lt;T&gt;::i() { return 1;}
     template &lt;class T&gt; typename Foo&lt;T&gt;::X Foo&lt;T&gt;::j() { return 1;}
</PRE>
In general, if you can match the declarations up using only information
from the template, then the declaration is valid.

<P>Declarations like <TT>Foo::i</TT> and <TT>Foo::j </TT>are invalid because
for a given instance of <TT>A&lt;T&gt;</TT>, <TT>A&lt;T&gt;::X</TT> may not actually
be int if the class is specialized.</P>

<P>This is not a problem for <TT>Foo::g1</TT> and <TT>Foo::g2</TT> because
for any instance of <TT>Foo&lt;T&gt;</TT> that is generated from the template
you know that Bar will always be int. If an instance of <TT>Foo</TT> is
specialized, the template member definitions are not used so it doesn't
matter whether a specialization defines <TT>Bar</TT> as int or not.</P>


<BR><BR><HR><A NAME="287"></A><H4>287.
  
Order dependencies in template instantiation
</H4><B>Section: </B>14.6.4.1&#160; [temp.point]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Martin Sebor
 &#160;&#160;&#160;

 <B>Date: </B>17 May 2001<BR>




<P>Implementations differ in their treatment of the following
code:</P>

<PRE>
    template &lt;class T&gt;
    struct A {
	typename T::X x;
    };

    template &lt;class T&gt;
    struct B {
	typedef T* X;
	A&lt;B&gt; a;
    };

    int main ()
    {
	B&lt;int&gt; b;
    }
</PRE>

<P>Some implementations accept it.  At least one rejects it
because the instantiation of <TT>A&lt;B&lt;int&gt; &gt;</TT>
requires that <TT>B&lt;int&gt;</TT> be complete, and it is
not at the point at which <TT>A&lt;B&lt;int&gt; &gt;</TT>
is being instantiated.</P>

<P><U>Erwin Unruh</U>:</P>

<P>In my view the programm is ill-formed. My reasoning:</P>

<UL>

<LI>you need a complete type <TT>B&lt;int&gt;</TT> because you declare
a variable in <TT>main</TT></LI>

<LI><TT>B&lt;int&gt;</TT> contains a member of type
<TT>A&lt;B&lt;int&gt; &gt;</TT>, so you need that complete.</LI>

<LI><TT>A&lt;B&lt;int&gt; &gt;</TT> tries to access
<TT>B&lt;int&gt;::X</TT>, which in turn needs <TT>B&lt;int&gt;</TT>
being complete.</LI>

</UL>

<P>So each class needs the other to be complete.</P>

<P>The problem can be seen much easier if you replace the typedef with</P>
<PRE>
    typedef T (*X) [sizeof(B::a)];
</PRE>

<P>Now you have a true recursion. The compiler cannot easily distinguish
between a true recursion and a potential recursion.</P>

<P><U>John Spicer</U>:</P>

<P>Using a class to form a qualified name does not require the class to be
complete, it only requires that the named member already have been declared.
In other words, this kind of usage is permitted:</P>

<PRE>
    class A {
        typedef int B;
        A::B ab;
    };
</PRE>

<P>In the same way, once <TT>B</TT> has been declared in <TT>A</TT>,
it is also visible to any template that uses <TT>A</TT> through a
template parameter.</P>

<P>The standard could be more clear in this regard, but there are two
notes that make this point.  Both 3.4.3.1 [class.qual] and
5.1.1 [expr.prim.general] paragraph 7 contain a note that says "a
class member can be referred to using a qualified-id at any point in
its potential scope (3.3.7 [basic.scope.class])."  A member's
potential scope begins at its point of declaration.</P>

<P>In other words, a class has three states: incomplete, being
completed, and complete.  The standard permits a qualified name to be
used once a name has been declared.  The quotation of the notes about
the potential scope was intended to support that.</P>

<P>So, in the original example, class <TT>A</TT> does not require the
type of <TT>T</TT> to be complete, only that it have already declared
a member <TT>X</TT>.</P>

<P><U>Bill Gibbons</U>:</P>

<P>The template and non-template cases are different.  In the non-template
case the order in which the members become declared is clear.  In the
template case the members of the instantiation are conceptually all
created at the same time.  The standard does not say anything about
trying to mimic the non-template case during the instantiation of a class
template.</P>

<P><U>Mike Miller</U>:</P>

<P>I think the relevant specification is 14.6.4.1 [temp.point] paragraph 3, dealing with the point of
instantiation:</P>

<BLOCKQUOTE>

For a class template specialization... if the specialization is
implicitly instantiated because it is referenced from within
another template specialization, if the context from which the
specialization is referenced depends on a template parameter, and
if the specialization is not instantiated previous to the
instantiation of the enclosing template, the point of
instantiation is immediately before the point of instantiation
of the enclosing template.  Otherwise, the point of instantiation
for such a specialization immediately precedes the namespace scope
declaration or definition that refers to the specialization.

</BLOCKQUOTE>

<P>That means that the point of instantiation of <TT>A&lt;B&lt;int&gt;
&gt;</TT> is before that of <TT>B&lt;int&gt;</TT>, not in the middle
of <TT>B&lt;int&gt;</TT> after the declaration of <TT>B::X</TT>, and
consequently a reference to <TT>B&lt;int&gt;::X</TT> from
<TT>A&lt;B&lt;int&gt; &gt;</TT> is ill-formed.</P>

<P>To put it another way, I believe John's approach requires that there
be an instantiation stack, with the results of partially-instantiated
templates on the stack being available to instantiations above them.
I don't think the Standard mandates that approach; as far as I can
see, simply determining the implicit instantiations that need to be
done, rewriting the definitions at their respective points of
instantiation with parameters substituted (with appropriate "forward
declarations" to allow for non-instantiating references), and
compiling the result normally should be an acceptable implementation
technique as well.  That is, the implicit instantiation of the
example (using, e.g., <TT>B_int</TT> to represent the generated name of the
<TT>B&lt;int&gt;</TT> specialization) could be something like</P>

<PRE>
        struct B_int;

        struct A_B_int {
            B_int::X x;    // error, incomplete type
        };

        struct B_int {
            typedef int* X;
            A_B_int a;
        };
</PRE>

<P><B>Notes from 10/01 meeting:</B></P>

<P>This was discussed at length.  The consensus was that the template case
should be treated the same as the non-template class case it terms of
the order in which members get declared/defined and classes get completed.</P>

<P><B>Proposed resolution:</B></P>

<P>
In 14.6.4.1 [temp.point] paragraph 3 change:</P>
<BLOCKQUOTE>
the point of instantiation is immediately before the point of
instantiation of the enclosing template. Otherwise, the point of
instantiation for such a specialization immediately precedes the
namespace scope declaration or definition that refers to the
specialization.
</BLOCKQUOTE>
<P> To:</P>
<BLOCKQUOTE>
the point of instantiation is <SPAN style="font-weight:bold;background-color:#A0FFA0">the same as</SPAN> the point of
instantiation of the enclosing template. Otherwise, the point of
instantiation for such a specialization immediately precedes the
<SPAN style="font-weight:bold;background-color:#A0FFA0">nearest enclosing declaration</SPAN>.
<SPAN style="font-weight:bold;background-color:#A0FFA0">[Note: The point of instantiation is still at namespace scope but
any declarations preceding the point of instantiation, even if not
at namespace scope, are considered to have been seen.]</SPAN>
</BLOCKQUOTE>

<P> Add following paragraph 3:</P>
<BLOCKQUOTE>
If an implicitly instantiated class template specialization, class
member specialization, or specialization of a class template references
a class, class template specialization, class member specialization, or
specialization of a class template containing a specialization reference
that directly or indirectly caused the instantiation, the requirements
of completeness and ordering of the class reference are applied in the
context of the specialization reference.
</BLOCKQUOTE>

<P>and the following example</P>

<PRE>
  template &lt;class T&gt; struct A {
          typename T::X x;
  };

  struct B {
          typedef int X;
          A&lt;B&gt; a;
  };

  template &lt;class T&gt; struct C {
          typedef T* X;
          A&lt;C&gt; a;
  };

  int main ()
  {
          C&lt;int&gt; c;
  }
</PRE>

<P><B>Notes from the October 2002 meeting:</B></P>

<P>This needs work.  Moved back to drafting status.</P>

<P>See also issues <A HREF="
     cwg_closed.html#595">595</A> and
<A HREF="
     cwg_defects.html#1330">1330</A>.</P>

<BR><BR><HR><A NAME="1258"></A><H4>1258.
  
&#8220;Instantiation context&#8221; differs from dependent lookup rules
</H4><B>Section: </B>14.6.4.1&#160; [temp.point]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-10<BR>




<P>C++11 expanded the lookup rules for dependent function calls
(14.6.4.2 [temp.dep.candidate] paragraph 1 bullet 2) to include functions
with internal linkage; previously only functions with external linkage
were considered.  However, 14.6.4.1 [temp.point] paragraph 6
still says,</P>

<BLOCKQUOTE>

The instantiation context of an expression that depends on the
template arguments is the set of declarations with external linkage
declared prior to the point of instantiation of the template
specialization in the same translation unit.

</BLOCKQUOTE>

<P>Presumably this wording was overlooked and should be harmonized with
the new specification.</P>

<BR><BR><HR><A NAME="1253"></A><H4>1253.
  
Generic non-template members
</H4><B>Section: </B>14.7&#160; [temp.spec]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-06<BR>




<P>Many statements in the Standard apply only to templates, for example,
14.6 [temp.res] paragraph 8:</P>

<BLOCKQUOTE>

If no valid specialization can be generated for a template definition,
and that template is not instantiated, the template definition is
ill-formed, no diagnostic required.

</BLOCKQUOTE>

<P>This clearly should apply to non-template member functions of class
templates, not just to templates per se.  Terminology should be established
to refer to these generic entities that are not actually templates.</P>

<P><B>Additional notes (August, 2012):</B></P>

<P>Among the generic entities that should be covered by such a term
are default function arguments, as they can be instantiated independently.
If <A HREF="
     cwg_defects.html#1330">issue 1330</A> is resolved as expected,
<I>exception-specification</I>s should also be covered by the same term.
</P>

<P>See also <A HREF="
     cwg_active.html#1484">issue 1484</A>.</P>

<BR><BR><HR><A NAME="212"></A><H4>212.
  
Implicit instantiation is not described clearly enough
</H4><B>Section: </B>14.7.1&#160; [temp.inst]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Christophe de Dinechin
 &#160;&#160;&#160;

 <B>Date: </B>7 Mar 2000<BR>




<P>Three points have been raised where the wording in
14.7.1 [temp.inst] may not be sufficiently clear.</P>

<OL>

<LI>

In paragraph 4, the statement is made that

<BLOCKQUOTE>

A class template specialization is implicitly instantiated...  if the
completeness of the class type affects the semantics of the program...

</BLOCKQUOTE>

<P>It is not clear what it means for the "completeness... [to affect]
the semantics."  Consider the following example:</P>

<PRE>
        template&lt;class T&gt; struct A;
        extern A&lt;int&gt; a;

        void *foo() { return &amp;a; }

        template&lt;class T&gt; struct A
        {
        #ifdef OPTION
                void *operator &amp;() { return 0; }
        #endif
        };
</PRE>

<P>The question here is whether it is necessary for template class
<TT>A</TT> to declare an <TT>operator &amp;</TT> for the semantics of the
program to be affected.  If it does not do so, the meaning of
<TT>&amp;a</TT> will be the same whether the class is complete or
not and thus arguably the semantics of the program are not
affected.</P>

<P>Presumably what was intended is whether the presence or absence of
certain member declarations in the template class might be relevant in
determining the meaning of the program.  A clearer statement may be
desirable.</P>

</LI>

<LI>

Paragraph 5 says,

<BLOCKQUOTE>

If the overload resolution process can determine the correct function
to call without instantiating a class template definition, it is
unspecified whether that instantiation actually takes place.

</BLOCKQUOTE>

<P>The intent of this wording, as illustrated in the example in that
paragraph, is to allow a "smart" implementation not to instantiate
class templates if it can determine that such an instantiation will
not affect the result of overload resolution, even though the
algorithm described in clause 13 [over] requires that
all the viable functions be enumerated, including functions that might
be found as members of specializations.</P>

<P>Unfortunately, the looseness of the wording allowing this latitude
for implementations makes it unclear what "the overload resolution
process" is &#8212; is it the algorithm in 13 [over] or
something else? &#8212; and what "the correct function" is.</P>

</LI>

<LI>

According to paragraph 6,

<BLOCKQUOTE>

If an implicit instantiation of a class template specialization is
required and the template is declared but not defined, the program is
ill-formed.

</BLOCKQUOTE>

<P>Here, it is not clear what conditions "require" an implicit
instantiation.  From the context, it would appear that the intent is
to refer to the conditions in paragraph 4 that cause a specialization
to be instantiated.</P>

<P>This interpretation, however, leads to different treatment of
template and non-template incomplete classes.  For example, by this
interpretation,</P>

<PRE>
    class A;
    template &lt;class T&gt; struct TA;
    extern A a;
    extern TA&lt;int&gt; ta;

    void f(A*);
    void f(TA&lt;int&gt;*);

    int main()
    {
        f(&amp;a);    // well-formed; undefined if A
                  // has operator &amp;() member
        f(&amp;ta);   // ill-formed: cannot instantiate
    }
</PRE>

<P>A different approach would be to understand "required" in paragraph
6 to mean that a complete type is required in the expression.  In this
interpretation, if an incomplete type is acceptable in the context and
the class template definition is not visible, the instantiation is not
attempted and the program is well-formed.</P>

<P>The meaning of "required" in paragraph 6 must be clarified.</P>

</LI>

</OL>

<P>(See also issues <A HREF="
     cwg_defects.html#204">204</A> and
<A HREF="
     cwg_defects.html#63">63</A>.)</P>

<P><B>Notes on 10/01 meeting:</B></P>

<P>It was felt that item 1 is solved by addition of the word "might"
in the resolution for <A HREF="
     cwg_defects.html#63">issue 63</A>; item 2
is not much of a problem; and item 3 could be solved by changing
"required" to "required to be complete".</P>

<BR><BR><HR><A NAME="1396"></A><H4>1396.
  
Deferred instantiation and checking of non-static data member initializers
</H4><B>Section: </B>14.7.1&#160; [temp.inst]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2011-09-22<BR>




<P>Non-static data member initializers get the same late parsing
as member functions and default arguments, but are they also
instantiated as needed like them?  And when is their validity
checked?</P>

<P><B>Notes from the October, 2012 meeting:</B></P>

<P>CWG agreed that non-static data member initializers should be handled
like default arguments.</P>

<P><B>Additional note (March, 2013):</B></P>

<P>Determining whether a defaulted constructor is <TT>constexpr</TT> or
not requires parsing the class's non-static data member initializers;
see also <A HREF="
     cwg_active.html#1360">issue 1360</A>.</P>

<BR><BR><HR><A NAME="1665"></A><H4>1665.
  
Declaration matching in explicit instantiations
</H4><B>Section: </B>14.7.2&#160; [temp.explicit]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-19<BR>




<P>Consider a case like</P>

<PRE>
  struct X {
    template&lt;typename T&gt; void f(T);
    void f(int);
  };
  template void X::f(int);
</PRE>

<P>or</P>

<PRE>
  template&lt;typename T&gt; void f(T) {}
  void f(int);
  template void f(int);
</PRE>

<P>Presumably in both these cases the explicit instantiation should
refer to the template and not to the non-template; however,
14.5.2 [temp.mem] paragraph 2 says,</P>

<BLOCKQUOTE>

A normal (non-template) member function with a given name and type and a
member function template of the same name, which could be used to generate
a specialization of the same type, can both be declared in a class. When
both exist, a use of that name and type refers to the non-template member
unless an explicit template argument list is supplied.

</BLOCKQUOTE>

<P>This would appear to give the wrong answer for the first example.
It's not clearly stated, but consistency would suggest a similar wrong
answer for the second.  Presumably a statement is needed somewhere that
an explicit instantiation directive applies to a template and not a
non-template function if both are visible.</P>

<BR><BR><HR><A NAME="1704"></A><H4>1704.
  
Type checking in explicit instantiation of variable templates
</H4><B>Section: </B>14.7.2&#160; [temp.explicit]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-06-20<BR>




<P>It is not clear whether the following is well-formed or not:</P>

<PRE>
  template&lt;typename T&gt; int arr[sizeof(T)] = {};
  template int arr&lt;int&gt;[];
</PRE>

<P>Are we supposed to instantiate the specialization and treat the explicit
instantiation declaration as if it were a redeclaration (in which case the
omitted array bound would presumably be OK), or is the type of the explicit
instantiation declaration required to exactly match the type that the
instantiated specialization has (in which case the omitted bound would
presumably not be OK)? Or something else?</P>

<P>(See also <A HREF="
     cwg_active.html#1728">issue 1728</A>.)</P>

<BR><BR><HR><A NAME="1728"></A><H4>1728.
  
Type of an explicit instantiation of a variable template
</H4><B>Section: </B>14.7.2&#160; [temp.explicit]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Larisse Voufo
 &#160;&#160;&#160;

 <B>Date: </B>2013-08-05<BR>




<P>It is not clear to what extent the type in an explicit instantiation
must match that of a variable template.  For example:</P>

<PRE>
  template&lt;typename T&gt; T var = T();
  template float var&lt;float&gt;;   //<SPAN style="font-family:Times;font-style:italic"> #1.</SPAN>
  template int* var&lt;int&gt;;      //<SPAN style="font-family:Times;font-style:italic"> #2.</SPAN>
  template auto var&lt;char&gt;;     //<SPAN style="font-family:Times;font-style:italic"> #3.</SPAN>
</PRE>

<P>(See also <A HREF="
     cwg_active.html#1704">issue 1704</A>.)</P>

<BR><BR><HR><A NAME="529"></A><H4>529.
  
Use of <TT>template&lt;&gt;</TT> with &#8220;explicitly-specialized&#8221; class templates
</H4><B>Section: </B>14.7.3&#160; [temp.expl.spec]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>16 August 2005<BR>


<P>Paragraph 17 of 14.7.3 [temp.expl.spec] says,</P>

<BLOCKQUOTE>

A member or a member template may be nested within many enclosing
class templates. In an explicit specialization for such a member, the
member declaration shall be preceded by a <TT>template&lt;&gt;</TT>
for each enclosing class template that is explicitly specialized.

</BLOCKQUOTE>

<P>This is curious, because paragraph 3 only allows explicit
specialization of members of implicitly-instantiated class
specializations, not explicit specializations.  Furthermore,
paragraph 4 says,</P>

<BLOCKQUOTE>

Definitions of members of an explicitly specialized class are defined
in the same manner as members of normal classes, and not using the
explicit specialization syntax.

</BLOCKQUOTE>

<P>Paragraph 18 provides a clue for resolving the apparent
contradiction:</P>

<BLOCKQUOTE>

In an explicit specialization declaration for a member of a class
template or a member template that appears in namespace scope, the
member template and some of its enclosing class templates may remain
unspecialized, except that the declaration shall not explicitly
specialize a class member template if its enclosing class templates
are not explicitly specialized as well. In such explicit
specialization declaration, the keyword <TT>template</TT> followed by
a <I>template-parameter-list</I> shall be provided instead of
the <TT>template&lt;&gt;</TT> preceding the explicit specialization
declaration of the member.

</BLOCKQUOTE>

<P>It appears from this and the following example that the phrase
&#8220;explicitly specialized&#8221; in paragraphs 17 and 18, when
referring to enclosing class templates, does not mean that explicit
specializations have been declared for them but that their names in
the <I>qualified-id</I> are followed by template argument lists.  This
terminology is confusing and should be changed.</P>

<P><B>Proposed resolution (October, 2005):</B></P>

<OL><LI><P>Change 14.7.3 [temp.expl.spec] paragraph 17 as
indicated:</P></LI>

<BLOCKQUOTE>

A member or a member template may be nested within many enclosing
class templates. In an explicit specialization for such a member, the
member declaration shall be preceded by a <TT>template&lt;&gt;</TT>
for each enclosing class template <SPAN style="text-decoration:line-through;background-color:#FFA0A0">that is explicitly specialized</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">specialization</SPAN>. [<I>Example:</I>...

</BLOCKQUOTE>

<LI><P>Change 14.7.3 [temp.expl.spec] paragraph 18 as
indicated:</P></LI>

<BLOCKQUOTE>

In an explicit specialization declaration for a member of a class
template or a member template that appears in namespace scope, the
member template and some of its enclosing class templates may remain
unspecialized, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">except that the declaration shall not explicitly
specialize a class member template if its enclosing class templates
are not explicitly specialized as well</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">that is, the
<I>template-id</I> naming the template may be composed of template
parameter names rather than <I>template-argument</I>s</SPAN>. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">In</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">For each unspecialized template in</SPAN> such <SPAN style="font-weight:bold;background-color:#A0FFA0">an</SPAN> explicit
specialization declaration, the keyword <TT>template</TT> followed by
a <I>template-parameter-list</I> shall be provided instead of
the <TT>template&lt;&gt;</TT> preceding the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">explicit
specialization</SPAN> declaration of the member. The types of
the <I>template-parameter</I>s in the <I>template-parameter-list</I>
shall be the same as those specified in the primary template
definition. <SPAN style="font-weight:bold;background-color:#A0FFA0">In such declarations, an unspecialized <I>template-id</I>
shall not precede the name of a template specialization in the
<I>qualified-id</I> naming the member.</SPAN> [<I>Example:</I>...

</BLOCKQUOTE>

</OL>

<P><B>Notes from the April, 2006 meeting:</B></P>

<P>The revised wording describing &#8220;unspecialized&#8221; templates
needs more work to ensure that the parameter names in the
<I>template-id</I> are in the correct order; the distinction between
template arguments and parameters is also probably not clear enough.  It
might be better to replace this paragraph completely and avoid the
&#8220;unspecialized&#8221; wording altogether.</P>

<P><B>Proposed resolution (February, 2010):</B></P>

<OL><LI><P>Change 14.7.3 [temp.expl.spec] paragraph 17 as follows:</P></LI>

<BLOCKQUOTE>

A member or a member template may be nested within many enclosing
class templates.  In an explicit specialization for such a
member, the member declaration shall be preceded by a
<TT>template&lt;&gt;</TT> for each enclosing class template
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">that is explicitly specialized</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">specialization</SPAN>. [<I>Example:</I>...

</BLOCKQUOTE>

<LI><P>Change 14.7.3 [temp.expl.spec] paragraph 18 as follows:</P></LI>

<BLOCKQUOTE>

In an explicit specialization declaration for a member of a
class template or a member template that appears in namespace
scope, the member template and some of its enclosing class
templates may remain unspecialized, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">except that the declaration
shall not explicitly specialize a class member template if its
enclosing class templates are not explicitly specialized as well.
In such explicit specialization declaration, the keyword
<TT>template</TT> followed by a <I>template-parameter-list</I>
shall be provided instead of the <TT>template&lt;&gt;</TT>
preceding the explicit specialization declaration of the member.
The types of the <I>template-parameter</I>s in the
<I>template-parameter-list</I> shall be the same as those
specified in the primary template definition.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">that is,
the corresponding template prefix may specify a
<I>template-parameter-list</I> instead of <TT>template&lt;&gt;</TT>
and the <I>template-id</I> naming the template be written using
those <I>template-parameter</I>s as <I>template-argument</I>s.
In such a declaration, the number, kinds, and types of the
<I>template-parameter</I>s shall be the same as those specified in
the primary template definition, and the <I>template-parameter</I>s
shall be named in the <I>template-id</I> in the same order that they
appear in the <I>template-parameter-list</I>.  An unspecialized
<I>template-id</I> shall not precede the name of a template
specialization in the <I>qualified-id</I> naming the member.</SPAN>
[<I>Example:</I>...

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1391"></A><H4>1391.
  
Conversions to parameter types with non deduced template arguments
</H4><B>Section: </B>14.8.1&#160; [temp.arg.explicit]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2011-09-08<BR>




<P>According to 14.8.1 [temp.arg.explicit] paragraph 6,</P>

<BLOCKQUOTE>

Implicit conversions (Clause 4 [conv]) will be
performed on a function argument to convert it to the type of the
corresponding function parameter if the parameter type contains
no <I>template-parameter</I>s that participate in template argument
deduction.  [<I>Note:</I> Template parameters do not participate in
template argument deduction if they are explicitly specified...

</BLOCKQUOTE>

<P>But this isn't clear about when these conversions are done.
Consider</P>

<PRE>
    template&lt;class T&gt; struct A {
       typename T::N n;
    };
    template&lt;class T&gt; struct B { };

    template&lt;class T, class T2&gt;
    void foo(const A&lt;T&gt;&amp; r); // #1
    template&lt;class T&gt;
    void foo(const B&lt;T&gt;&amp; r); // #2

    void baz() {
       B&lt;char&gt; b;
       foo(b); // OK
       foo&lt;char&gt;(b); // error
    }
</PRE>

<P>With the explicit template argument, the first parameter of #1
no longer participates in template argument deduction, so
implicit conversions are done.  If we check for the implicit
conversion during the deduction process, we end up instantiating
<TT>A&lt;char&gt;</TT>, resulting in a hard error.  If we wait
until later to check the conversion, we can reject #1 because
<TT>T2</TT> is not deduced and never need to consider the
conversion.</P>

<P>But if we just accept the parameter and leave it up to normal
overload resolution to reject an unsuitable candidate, that
breaks this testcase:</P>

<PRE>
    template&lt;class T&gt;
    struct A {
       typename T::N n;
    };

    template&lt;class T&gt;
    struct B { };

    template &lt;class T, class... U&gt;
    typename A&lt;T&gt;::value_t bar(int, T, U...);

    template &lt;class T&gt;
    T bar(T, T);

    void baz()
    {
       B&lt;char&gt; b;
       bar(b, b);
    }
</PRE>

<P>Here, if deduction succeeds, we substitute in the deduced
arguments of <TT>T = B&lt;char&gt;, U = { }</TT>, and end up
instantiating <TT>A&lt;B&lt;char&gt;&gt;</TT>, which fails.</P>

<P>EDG and GCC currently reject the first testcase and accept the
second; clang accepts both.</P>

<P><B>Notes from the October, 2012 meeting:</B></P>

<P>The position initially favored by CWG was that implicit conversions
are not considered during deduction but are only applied afterwards,
so the second example is ill-formed, and that the normative wording of
the referenced paragraph should be moved into the note.  This approach
does not handle some examples currently accepted by some implementations,
however; for example:</P>

<PRE>
   template &lt;class T&gt; struct Z {
    typedef T::x xx;
   };
   template &lt;class T&gt; Z&lt;T&gt;::xx f(void *, T);
   template &lt;class T&gt; void f(int, T);
   struct A {} a;
   int main() {
     f(1, a); //<SPAN style="font-family:Times;font-style:italic"> If the implementation rules out the first overload</SPAN>
              //<SPAN style="font-family:Times;font-style:italic"> because of the invalid conversion from </SPAN>int<SPAN style="font-family:Times;font-style:italic"> to </SPAN>void*<SPAN style="font-family:Times;font-style:italic">,</SPAN>
              //<SPAN style="font-family:Times;font-style:italic"> the error instantiating </SPAN>Z&lt;A&gt;<SPAN style="font-family:Times;font-style:italic"> will be avoided</SPAN>
   }
</PRE>

<P>Additional discussion is required.</P>

<P><B>Notes from the April, 2013 meeting:</B></P>

<P>The approach needed to accept this code appears to be doing the
convertibility check between deduction and substitution.</P>

<BR><BR><HR><A NAME="1172"></A><H4>1172.
  
&#8220;instantiation-dependent&#8221; constructs
</H4><B>Section: </B>14.8.2&#160; [temp.deduct]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-05<BR>


<P>There are certain constructs that are not covered by the existing
categories of &#8220;type dependent&#8221; and &#8220;value
dependent.&#8221;  For example, the expression
<TT>sizeof(sizeof(T()))</TT> is neither type-dependent nor
value-dependent, but its validity depends on whether <TT>T</TT>
can be value-constructed.  We should be able to overload on
such characteristics and select via deduction failure, but we
need a term like &#8220;instantiation-dependent&#8221; to
describe these cases in the Standard.  The phrase &#8220;expression
involving a template parameter&#8221; seems to come pretty close to
capturing this idea.</P>

<P><B>Notes from the November, 2010 meeting:</B></P>

<P>The CWG favored extending the concepts of &#8220;type-dependent&#8221;
and &#8220;value-dependent&#8221; to cover these additional cases,
rather than adding a new concept.</P>

<P><B>Notes from the March, 2011 meeting:</B></P>

<P>The CWG reconsidered the direction from the November, 2010 meeting,
as it would make more constructs dependent, thus requiring more
<TT>template</TT> and <TT>typename</TT> keywords, resulting in worse
error messages, etc.</P>

<P><B>Notes from the August, 2011 meeting:</B></P>

<P>The following example (from <A HREF="
     cwg_closed.html#1273">issue 1273</A>)
was deemed relevant for this issue:</P>

<PRE>
    template &lt;class T&gt; struct C;

    class A {
       int i;
       friend struct C&lt;int&gt;;
    } a;

    class B {
       int i;
       friend struct C&lt;float&gt;;
    } b;

    template &lt;class T&gt;
    struct C {
       template &lt;class U&gt; decltype (a.i) f() { } // #1
       template &lt;class U&gt; decltype (b.i) f() { } // #2
    };

    int main() {
       C&lt;int&gt;().f&lt;int&gt;();     // calls #1
       C&lt;float&gt;().f&lt;float&gt;(); // calls #2
    }
</PRE>



<BR><BR><HR><A NAME="1322"></A><H4>1322.
  
Function parameter type decay in templates
</H4><B>Section: </B>14.8.2&#160; [temp.deduct]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2011-05-19<BR>




<P>The discussion of <A HREF="
     cwg_active.html#1001">issue 1001</A> seemed to have
settled on the approach of doing the 8.3.5 [dcl.fct]
transformations immediately to the function template declaration, so
that the original form need not be remembered.  However, the example
in 14.8.2 [temp.deduct] paragraph 8 suggests otherwise:</P>

<PRE>
  template &lt;class T&gt; int f(T[5]);
  int I = f&lt;int&gt;(0);
  int j = f&lt;void&gt;(0); //<SPAN style="font-family:Times;font-style:italic"> invalid array</SPAN>
</PRE>

<P>One way that might be addressed would be to separate the concepts
of the type of the template that participates in overload resolution and
function matching from the type of the template that is the source for
template argument substitution.  (See also the example in paragraph 3 of
the same section.)</P>

<P><B>Notes, January, 2012:</B></P>

<P></P>

<BR><BR><HR><A NAME="1582"></A><H4>1582.
  
Template default arguments and deduction failure
</H4><B>Section: </B>14.8.2&#160; [temp.deduct]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2012-10-31<BR>


<P>According to 14.8.2 [temp.deduct] paragraph 5,</P>

<BLOCKQUOTE>

The resulting substituted and adjusted function type is used as the
type of the function template for template argument deduction. If a
template argument has not been deduced and its corresponding template
parameter has a default argument, the template argument is determined
by substituting the template arguments determined for preceding
template parameters into the default argument.  If the substitution
results in an invalid type, as described above, type deduction fails.

</BLOCKQUOTE>

<P>This leaves the impression that default arguments are used after
deduction failure leaves an argument undeduced.  For example,</P>

<PRE>
  template&lt;typename T&gt; struct Wrapper;
  template&lt;typename T = int&gt; void f(Wrapper&lt;T&gt;*);
  void g() {
    f(0);
  }
</PRE>

<P>Deduction fails for <TT>T</TT>, so presumably <TT>int</TT> is used.
However, some implementations reject this code.  It appears that the
intent would be better expressed as something like</P>

<BLOCKQUOTE>

...If a template argument is used only in a non-deduced context and
its corresponding template parameter has a default argument...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1724"></A><H4>1724.
  
Unclear rules for deduction failure
</H4><B>Section: </B>14.8.2&#160; [temp.deduct]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>2013-07-31<BR>




<P>According to 14.8.2 [temp.deduct] paragraph 8,</P>

<BLOCKQUOTE>

If a substitution results in an invalid type or expression, type deduction
fails. An invalid type or expression is one that would be ill-formed, with
a diagnostic required, if written using the substituted arguments.

</BLOCKQUOTE>

<P>Presumably the phrase &#8220;if written&#8221; refers to rewriting the
template declaration <I>in situ</I> with the substituted arguments, rather
than writing that type or expression at some arbitrary location, e.g.,</P>

<PRE>
  void g(double) = delete;

  template&lt;class T&gt; auto f(T t) -&gt; decltype(g(t));

  void g(int);

  void h() {
    typedef int T;
    T t = 42;
    g(t);  //<SPAN style="font-family:Times;font-style:italic"> Ok (I &#8220;wrote the substituted arguments&#8221;, and it seems fine)</SPAN>
    f(42); //<SPAN style="font-family:Times;font-style:italic"> Presumably substitution is meant to fail.</SPAN>
  }
</PRE>

<P>Perhaps a clearer formulation could be used?</P>

<BR><BR><HR><A NAME="1513"></A><H4>1513.
  
<TT>initializer_list</TT> deduction failure
</H4><B>Section: </B>14.8.2.1&#160; [temp.deduct.call]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>2012-06-28<BR>


<P>According to 14.8.2.1 [temp.deduct.call] paragraph 1,</P>

<BLOCKQUOTE>

If removing references and cv-qualifiers from <TT>P</TT> gives
<TT>std::initializer_list&lt;<I>P'</I>&gt;</TT> for some
<TT><I>P'</I></TT> and the argument is an initializer list
(8.5.4 [dcl.init.list]), then deduction is performed instead for
each element of the initializer list, taking <TT><I>P'</I></TT> as a
function template parameter type and the initializer element as its
argument. Otherwise, an initializer list argument causes the parameter
to be considered a non-deduced context (14.8.2.5 [temp.deduct.type]).

</BLOCKQUOTE>

<P>It is not entirely clear whether the deduction for an initializer
list meeting a <TT>std::initializer_list&lt;T&gt;</TT> is a recursive
subcase, or part of the primary deduction.  A relevant question is:
if the deduction on that part fails, does the entire deduction fail,
or is the parameter to be considered non-deduced?
</P>

<P><B>Notes from the October, 2012 meeting:</B></P>

<P>CWG determined that the entire deduction fails in this case.</P>

<BR><BR><HR><A NAME="1591"></A><H4>1591.
  
Deducing array bound and element type from initializer list
</H4><B>Section: </B>14.8.2.1&#160; [temp.deduct.call]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Peter Dimov
 &#160;&#160;&#160;

 <B>Date: </B>2012-12-01<BR>




<P>Currently, 14.8.2.1 [temp.deduct.call] paragraph 1 says,</P>

<BLOCKQUOTE>

Template argument deduction is done by comparing each function
template parameter type (call it <TT>P</TT>) with the type of the
corresponding argument of the call (call it <TT>A</TT>) as described
below.  If removing references and cv-qualifiers from <TT>P</TT> gives
<TT>std::initializer_list&lt;</TT><I>P'</I><TT>&gt;</TT> for some
<I>P'</I> and the argument is an initializer list (8.5.4 [dcl.init.list]), then deduction is performed instead for each element
of the initializer list, taking <I>P'</I> as a function template
parameter type and the initializer element as its argument. Otherwise,
an initializer list argument causes the parameter to be considered a
non-deduced context (14.8.2.5 [temp.deduct.type]).

</BLOCKQUOTE>

<P>It would seem reasonable, however, to allow an array bound to be
deduced from the number of elements in the initializer list, e.g.,</P>

<PRE>
  template&lt;int N&gt; void g(int const (&amp;)[N]);
  void f() {
    g( { 1, 2, 3, 4 } );
  }
</PRE>

<P><B>Additional note (March, 2013):</B></P>

<P>The element type should also be deducible.
</P>

<BR><BR><HR><A NAME="1486"></A><H4>1486.
  
Base-derived conversion in member pointer deduction
</H4><B>Section: </B>14.8.2.2&#160; [temp.deduct.funcaddr]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2012-03-26<BR>


<P>The rules for deducing template arguments when taking the address of a
function template in 14.8.2.2 [temp.deduct.funcaddr] do not appear to allow
for a base-to-derived conversion in a case like:</P>

<PRE>
  struct Base {
    template&lt;class U&gt; void f(U);
  };

  struct Derived : Base { };

  int main() {
    void (Derived::*pmf)(int) = &amp;Derived::f;
  } 
</PRE>

<P>Most implementations appear to allow this adjustment, however.</P>

<BR><BR><HR><A NAME="1610"></A><H4>1610.
  
Cv-qualification in deduction of reference to array
</H4><B>Section: </B>14.8.2.4&#160; [temp.deduct.partial]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-01-28<BR>


<P>Given</P>

<PRE>
   template&lt;class C&gt; void foo(const C* val) {}
   template&lt;int N&gt; void foo(const char (&amp;t)[N]) {}
</PRE>

<P>it is intuitive that the second template is more specialized than
the first.  However, the current rules make them unordered.
In 14.8.2.4 [temp.deduct.partial] paragraph 4, we have P as
<TT>const C*</TT> and A as <TT>const char (&amp;)[N]</TT>.  Paragraph 5
transforms A to <TT>const char[N]</TT>.  Finally, paragraph 7 removes
top-level cv-qualification; since a cv-qualified array element type is
considered to be cv-qualification of the array (3.9.3 [basic.type.qualifier]
paragraph 5, cf <A HREF="
     cwg_defects.html#1059">issue 1059</A>), A
becomes <TT>char[N]</TT>.  P remains <TT>const C*</TT>, so deduction fails
because of the missing <TT>const</TT> in A.</P>

<P><B>Notes from the April, 2013 meeting:</B></P>

<P>CWG agreed that the <TT>const</TT> should be preserved in the
array type.</P>

<BR><BR><HR><A NAME="1395"></A><H4>1395.
  
Partial ordering of variadic templates reconsidered
</H4><B>Section: </B>14.8.2.5&#160; [temp.deduct.type]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2011-09-21<BR>




<P>The resolution of <A HREF="
     cwg_defects.html#692">issue 692</A> (found in
document N3281) made the following example ambiguous and thus
ill-formed:</P>

<PRE>
    template&lt;class T&gt;
    void print(ostream &amp;os, const T &amp;t) {
        os &lt;&lt; t;
    }

    template &lt;class T, class... Args&gt;
    void print(ostream &amp;os, const T &amp;t, const Args&amp;... rest) {
        os &lt;&lt; t &lt;&lt; ", ";
        print(os, rest...);
    }

    int main() {
        print(cout, 42);
        print(cout, 42, 1.23);
    }
</PRE>

<P>This pattern seems fairly intuitive; is it reason to reconsider or
modify the outcome of <A HREF="
     cwg_defects.html#692">issue 692</A>?</P>

<P>(See also <A HREF="
     cwg_active.html#1432">issue 1432</A>.)</P>

<P><B>Notes from the October, 2012 meeting:</B></P>

<P>CWG agreed that the example should be accepted, handling this case
as a late tiebreaker, preferring an omitted parameter over a parameter
pack.</P>

<P><B>Additional note (March, 2013):</B></P>

<P>For another example:</P>

<PRE>
  template&lt;typename ...T&gt; int f(T*...) {
    return 1;
  }
  template&lt;typename T&gt; int f(const T&amp;) {
    return 2;
  }
  int main() {
    if (f((int*)0) != 1) {
       return 1;
    }
    return 0;
  }
</PRE>

<P>This worked as expected prior to the resolution of
<A HREF="
     cwg_defects.html#692">issue 692</A>.</P>

<BR><BR><HR><A NAME="1436"></A><H4>1436.
  
Interaction of constant expression changes with preprocessor expressions
</H4><B>Section: </B>16.1&#160; [cpp.cond]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2012-01-02<BR>




<P>It appears that some of the recent changes to the description of
constant expressions have allowed constructs into preprocessor
expressions that do not belong there.  Some changes are required to
restrict the current capabilities of constant expressions to what
is intended to be allowed in preprocessor expressions.</P>

<P><B>Proposed resolution (February, 2012):</B></P>

<OL><LI><P>Change 16.1 [cpp.cond] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

Each preprocessing token that remains (in the list of preprocessing
tokens that will become the controlling expression) after all macro
replacements have occurred shall be in the lexical form of a token
(2.7 [lex.token]). <SPAN style="font-weight:bold;background-color:#A0FFA0">Any such token that is a literal
(2.14.1 [lex.literal.kinds]) shall be an <I>integer-literal</I>, a
<I>character-literal</I>, or a <I>boolean-literal</I>.</SPAN>

</BLOCKQUOTE>

<LI><P>Change 16.1 [cpp.cond] paragraph 4 as follows:</P></LI>

<BLOCKQUOTE>

...using arithmetic that has at least the ranges specified in
18.3 [support.limits]. <SPAN style="font-weight:bold;background-color:#A0FFA0">The only operators permitted in the
controlling constant expression are <TT>?:</TT>, <TT>||</TT>,
<TT>&amp;&amp;</TT>, <TT>|</TT>, <TT>^</TT>, <TT>&amp;</TT>,
<TT>==</TT>, <TT>!=</TT>, <TT>&lt;</TT>, <TT>&lt;=</TT>,
<TT>&gt;</TT>, <TT>&gt;=</TT>, <TT>&lt;&lt;</TT>, <TT>&gt;&gt;</TT>,
<TT>-</TT>, <TT>+</TT>, <TT>*</TT>, <TT>/</TT>, <TT>%</TT>,
<TT>!</TT>, and <TT>~</TT>.</SPAN> For the purposes of this token
conversion...

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1335"></A><H4>1335.
  
Stringizing, extended characters, and universal-character-names
</H4><B>Section: </B>16.3.2&#160; [cpp.stringize]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2011-07-03<BR>




<P>When a string literal containing an extended character is
stringized (16.3.2 [cpp.stringize]), the result contains a
universal-character-name instead of the original extended character.
The reason is that the extended character is translated to a
universal-character-name in translation phase 1 (2.2 [lex.phases]), so that the string literal <TT>"@"</TT> (where <TT>@</TT>
represents an extended character) becomes <TT>"\uXXXX"</TT>.  Because
the preprocessing token is a string literal, when the stringizing
occurs in translation phase 4, the <TT>\</TT> is doubled, and the
resulting string literal is <TT>"\"\\uXXXX\""</TT>.  As a result, the
universal-character-name is not recognized as such when the translation
to the execution character set occurs in translation phase 5.  (Note
that phase 5 translation does occur if the stringized extended character
does not appear in a string literal.)  Existing practice appears to
ignore these rules and preserve extended characters in stringized
string literals, however.</P>

<P>See also <A HREF="
     cwg_active.html#578">issue 578</A>.</P>

<P><B>Additional note (August, 2013):</B></P>

<P>Implementations are granted substantial latitude in their
handling of extended characters and universal-character-names in
2.2 [lex.phases] paragraph 1 phase 1, i.e.,</P>

<BLOCKQUOTE>

(An implementation may use any internal encoding, so long as an actual
extended character encountered in the source file, and the same extended
character expressed in the source file as a universal-character-name (i.e.,
using the <TT>\uXXXX</TT> notation), are handled equivalently except where
this replacement is reverted in a raw string literal.)

</BLOCKQUOTE>

<P>However, this freedom is mostly nullified by the requirements of
stringizing in 16.3.2 [cpp.stringize] paragraph 2:</P>

<BLOCKQUOTE>

If, in the replacement list, a parameter is immediately preceded by
a <TT>#</TT> preprocessing token, both are replaced by a single character
string literal preprocessing token that contains the spelling of the
preprocessing token sequence for the corresponding argument.

</BLOCKQUOTE>

<P>This means that, in order to handle a construct like</P>

<PRE>
  #define STRINGIZE_LITERAL( X ) # X
  #define STRINGIZE( X ) STRINGIZE_LITERAL( X )

  STRINGIZE( STRINGIZE( identifier_\u00fC\U000000Fc ) ) 
</PRE>

<P>an implementation must recall the original spelling, including
the form of UCN and the capitalization of any non-numeric hexadecimal
digits, rather than simply translating the characters into a convenient
internal representation.</P>

<P>To effect the freedom asserted in 2.2 [lex.phases], the
description of stringizing should make the spelling of a
universal-character-name implementation-defined.</P>

<BR><BR><HR><A NAME="1709"></A><H4>1709.
  
Stringizing raw string literals containing newline
</H4><B>Section: </B>16.3.2&#160; [cpp.stringize]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>David Krauss
 &#160;&#160;&#160;

 <B>Date: </B>2013-07-01<BR>


<P>Stringizing a raw string literal containing a newline produces an
invalid (unterminated) string literal and hence results in undefined
behavior.  It should be specified that a newline in a string literal is
transformed to the two characters <TT>'\' 'n'</TT> in the resulting string
literal.</P>

<P>A slightly related case involves stringizing a bare backslash
character: because backslashes are only escaped within a string or
character literal, a stringized bare backslash becomes <TT>"\"</TT>,
which is invalid and hence results in undefined behavior.</P>

<BR><BR><HR><A NAME="1279"></A><H4>1279.
  
Additional differences between C++ 2003 and C++ 2011
</H4><B>Section: </B>C.2&#160; [diff.cpp03]
 &#160;&#160;&#160;

 <B>Status: </B>drafting
 &#160;&#160;&#160;

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-27<BR>




<P>A number of differences between C++03 and C++11 were omitted from
C.2 [diff.cpp03]:</P>

<UL><LI><P>New keywords.  Although these are said in C.2.1 [diff.cpp03.lex] only to invalidate C++03 code, they can also change
the meaning, e.g., <TT>thread_local x(y)</TT>, which would declare
a variable <TT>thread_local</TT> initialized with <TT>y</TT> in
C++03 and a thread-local variable <TT>y</TT> in C++11.</P></LI>

<LI><P>New deduction rules.</P></LI>

<LI><P>Removal of the deprecated string literal conversion.</P></LI>

<LI><P>When a <TT>friend</TT> function defined in a class template
is actually defined (i.e., with each instantiation or only when
odr-used).</P></LI>

<LI><P>Removal of access declarations.</P></LI>

<LI><P>Use of the injected-class-name of a class template as a
template <I>template-argument</I>.</P></LI>

</UL>

<P><B>Additional note (January, 2012):</B></P>

<P>In addition to the items previously mentioned, access declarations
were removed from C++11 but are not mentioned in C.2 [diff.cpp03].</P>

<P><B>Proposed (partial) resolution (February, 2012):</B></P>

<P>Add the following as a new section in C.2 [diff.cpp03]:</P>

<BLOCKQUOTE>

<P><TABLE width="100%"><TR><TD><B>C.2.5 Clause 11 [class.access]: member access control</B></TD>
<TD align="right"><B>pdiff.cpp03.class.access</B></TD>

</TR>

</TABLE></P>

<P><B>Change:</B> Remove access declarations.</P>

<P><B>Rationale:</B> Removal of feature deprecated since C++ 1998.</P>

<P><B>Effect on original feature:</B> Valid C++ 2003 code that uses
access declarations is ill-formed in this International Standard.
Instead, <I>using-declaration</I>s (7.3.3 [namespace.udecl]) can
be used.</P>

</BLOCKQUOTE>

<BR><BR><BR><BR><HR><A NAME="Open Status"></A><H3>Issues with "Open" Status</H3>
<HR><A NAME="916"></A><H4>916.
  
Does a reference type have a destructor?
</H4><B>Section: </B>_N2914_.14.10.2.1&#160; [concept.map.fct]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>12 June, 2009<BR>




<P>Is the following well-formed?</P>

<PRE>
    auto concept HasDestructor&lt;typename T&gt; {
      T::~T();
    }

    concept_map HasDestructor&lt;int&amp;&gt; { }
</PRE>

<P>According to _N2914_.14.10.2.1 [concept.map.fct] paragraph 4, the
destructor requirement in the concept map results in an expression
<TT>x.~X()</TT>, where <TT>X</TT> is the type <TT>int&amp;</TT>.
According to 5.2.4 [expr.pseudo], this expression is ill-formed
because the object type and the <I>type-name</I> must be the same type,
but the object type cannot be a reference type (references are dropped
from types used in expressions, 5 [expr] paragraph 5).</P>

<P>It is not clear whether this should be addressed by changing
5.2.4 [expr.pseudo] or _N2914_.14.10.2.1 [concept.map.fct].</P>

<BR><BR><HR><A NAME="783"></A><H4>783.
  
Definition of &#8220;argument&#8221;
</H4><B>Section: </B>1.3&#160; [intro.defs]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>UK
 &#160;&#160;&#160;

 <B>Date: </B>3 March, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#UK3">N2800 comment
  UK&#160;3<BR></A>

<P>The definition of an argument does not seem to cover 
many assumed use cases, and we believe that is not 
intentional. There should be answers to
questions such as: Are lambda-captures 
arguments? Are type names in a throw-spec 
arguments? &#8220;Argument&#8221; to casts, typeid, alignof, 
alignas, decltype and sizeof? why in x[arg] arg is 
not an argument, but the value forwarded to 
operator[]() is? Does not apply to operators as 
call-points not bounded by parentheses? Similar 
for copy initialization and conversion? What are 
deduced template &#8220;arguments?&#8221; what are &#8220;default 
arguments?&#8221; can attributes have arguments? What 
about concepts, requires clauses and 
concept_map instantiations? What about user-defined
literals where parens are not used?</P>

<BR><BR><HR><A NAME="949"></A><H4>949.
  
Requirements for freestanding implementations
</H4><B>Section: </B>1.4&#160; [intro.compliance]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Detlef Vollman
 &#160;&#160;&#160;

 <B>Date: </B>2 August, 2009<BR>




<P>According to 1.4 [intro.compliance] paragraph 7,</P>

<BLOCKQUOTE>

A freestanding implementation is one in which execution may take place
without the benefit of an operating system, and has an
implementation-defined set of libraries that includes certain
language-support libraries (17.6.1.3 [compliance]).

</BLOCKQUOTE>

<P>This definition links two relatively separate topics: the lack
of an operating system and the minimal set of libraries.
Furthermore, 3.6.1 [basic.start.main] paragraph 1 says:</P>

<BLOCKQUOTE>

[<I>Note:</I> in a freestanding environment, start-up and termination
is implementation-defined; start-up contains the execution of
constructors for objects of namespace scope with static storage
duration; termination contains the execution of destructors for
objects with static storage duration. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<P>It would be helpful if the two characteristics (lack of an
operating system and restricted set of libraries) were named
separately and if these statements were clarified to identify exactly
what is implementation-defined.</P>

<P><B>Notes from the October, 2009 meeting:</B></P>

<P>The CWG felt that it needed a specific proposal in a paper before
attempting to resolve this issue.</P>

<BR><BR><HR><A NAME="698"></A><H4>698.
  
The definition of &#8220;sequenced before&#8221; is too narrow
</H4><B>Section: </B>1.9&#160; [intro.execution]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jens Maurer
 &#160;&#160;&#160;

 <B>Date: </B>13 July, 2008<BR>




<P>According to 1.9 [intro.execution] paragraph 14, &#8220;sequenced
before&#8221; is a relation between &#8220;evaluations.&#8221;  However,
3.6.3 [basic.start.term] paragraph 3 says,</P>

<BLOCKQUOTE>

If the completion of the initialization of a non-local object with
static storage duration is sequenced before a call to
<TT>std::atexit</TT> (see <TT>&lt;cstdlib&gt;</TT>, 18.5 [support.start.term]), the call to the function passed to <TT>std::atexit</TT>
is sequenced before the call to the destructor for the object. If a
call to <TT>std::atexit</TT> is sequenced before the completion of the
initialization of a non-local object with static storage duration, the
call to the destructor for the object is sequenced before the call to
the function passed to <TT>std::atexit</TT>. If a call to
<TT>std::atexit</TT> is sequenced before another call to
<TT>std::atexit</TT>, the call to the function passed to the second
<TT>std::atexit</TT> call is sequenced before the call to the function
passed to the first <TT>std::atexit</TT> call.

</BLOCKQUOTE>

<P>Except for the calls to <TT>std::atexit</TT>, these events do not
correspond to &#8220;evaluation&#8221; of expressions that appear in
the program.  If the &#8220;sequenced before&#8221; relation is to be
applied to them, a more comprehensive definition is needed.</P>

<BR><BR><HR><A NAME="578"></A><H4>578.
  
Phase 1 replacement of characters with <I>universal-character-name</I>s
</H4><B>Section: </B>2.2&#160; [lex.phases]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Martin Vejn&#225;r
 &#160;&#160;&#160;

 <B>Date: </B>7 May 2006<BR>


<P>According to 2.2 [lex.phases] paragraph 1, in translation
phase 1,</P>

<BLOCKQUOTE>

Any source file character not in the basic source character set
(2.3 [lex.charset]) is replaced by the
universal-character-name that designates that character.

</BLOCKQUOTE>

<P>If a character that is not in the basic character set is preceded
by a backslash character, for example</P>

<PRE>
    "\&#225;"
</PRE>

<P>the result is equivalent to</P>

<PRE>
    "\\u00e1"
</PRE>

<P>that is, a backslash character followed by the spelling of the
universal-character-name.  This is different from the result in C99,
which accepts characters from the extended source character set without
replacing them with universal-character-names.</P>

<P>See also <A HREF="
     cwg_active.html#1335">issue 1335</A>.</P>

<BR><BR><HR><A NAME="1698"></A><H4>1698.
  
Files ending in <TT>\</TT>
</H4><B>Section: </B>2.2&#160; [lex.phases]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>David Krauss
 &#160;&#160;&#160;

 <B>Date: </B>2013-06-10<BR>


<P>The description of how to handle file not ending in a newline in
2.2 [lex.phases] paragraph 1, phase 2, is:</P>

<OL START="2"><LI><P>Each instance of a backslash character (<TT>\</TT>)
immediately followed by a new-line character is deleted, splicing physical
source lines to form logical source lines. Only the last backslash on any
physical source line shall be eligible for being part of such a splice. If,
as a result, a character sequence that matches the syntax of a
universal-character-name is produced, the behavior is undefined. A source
file that is not empty and that does not end in a new-line character, or
that ends in a new-line character immediately preceded by a backslash
character before any such splicing takes place, shall be processed as if an
additional new-line character were appended to the file.</P></LI>

</OL>

<P>This is not clear regarding what happens if the last character in the
file is a backslash.  In such a case, presumably the result of adding the
newline should not be a line splice but rather a
backslash <I>preprocessing-token</I> (that will be diagnosed as an invalid
token in phase 7), but that should be spelled out.</P>

<BR><BR><HR><A NAME="1403"></A><H4>1403.
  
Universal-character-names in comments
</H4><B>Section: </B>2.8&#160; [lex.comment]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>David Krauss
 &#160;&#160;&#160;

 <B>Date: </B>2011-10-05<BR>


<P>According to 2.3 [lex.charset] paragraph 2,</P>

<BLOCKQUOTE>

If the hexadecimal value for a universal-character-name
corresponds to a surrogate code point (in the range
0xD800-0xDFFF, inclusive), the program is
ill-formed. Additionally, if the hexadecimal value for a
universal-character-name outside the <I>c-char-sequence</I>,
<I>s-char-sequence</I>, or <I>r-char-sequence</I> of a character
or string literal corresponds to a control character (in either
of the ranges 0x00-0x1F or 0x7F-0x9F, both inclusive) or to a
character in the basic source character set, the program is
ill-formed.

</BLOCKQUOTE>

<P>These restrictions should not apply to comment text.  Arguably
the prohibitions of control characters and characters in the basic
character set already do not apply, as they require that the
preprocessing tokens for literals have already been recognized; this
occurs in phase 3, which also replaces comments with single spaces.
However, the prohibition of surrogate code points is not so limited
and might conceivably be applied within comments.</P>

<P>Probably the most straightforward way of addressing this problem
would be simply to state in 2.8 [lex.comment] that
character sequences that resemble universal-character-names are not
recognized as such within comment text.</P>

<BR><BR><HR><A NAME="411"></A><H4>411.
  
Use of universal-character-name in character versus string literals
</H4><B>Section: </B>2.14.5&#160; [lex.string]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>James Kanze
 &#160;&#160;&#160;

 <B>Date: </B>23 Apr 2003<BR>


<P>2.14.5 [lex.string] paragraph 5 reads</P>
<BLOCKQUOTE>
Escape sequences and
universal-character-names in string literals have the same meaning as in
character literals, except that the single quote ' is representable
either by itself or by the escape sequence \', and the double quote "
shall be preceded by a \. In a narrow string literal, a
universal-character-name may map to more than one char element due to
multibyte encoding.
</BLOCKQUOTE>

<P>The first sentence refers us to 2.14.3 [lex.ccon],
where we read in the
first paragraph that "An ordinary character literal that contains a
single c-char has type char [...]."  Since the grammar shows that a
universal-character-name is a c-char, something like '\u1234' must have
type char (and thus be a single char element); in paragraph 5, we read
that "A universal-character-name is translated to the encoding, in the
execution character set, of the character named.  If there is no such
encoding, the universal-character-name is translated to an
implemenation-defined encoding."</P>

<P>This is in obvious contradiction with the second sentence.  In addition,
I'm not really clear what is supposed to happen in the case where the
execution (narrow-)character set is UTF-8.  Consider the character
\u0153 (the oe in the French word oeuvre).  Should '\u0153' be a char,
with an "error" value, say '?' (in conformance with the requirement that
it be a single char), or an int, with the two char values 0xC5, 0x93, in
an implementation defined order (in conformance with the requirement
that a character representable in the execution character set be
represented).  Supposing the former, should "\u0153" be the equivalent of
"?" (in conformance with the first sentence), or "\xC5\x93" (in
conformance with the second).</P>

<P><B>Notes from October 2003 meeting:</B></P>

<P>We decided we should forward this to the C committee and let them
resolve it.  Sent via e-mail to John Benito on November 14, 2003.</P>

<P><B>Reply from John Benito:</B></P>
<BLOCKQUOTE>
<P>I talked this over with the C project editor, we believe this was
handled by the C committee before publication of the current standard.</P>

<P>WG14 decided there needed to be a more restrictive rule 
for one-to-one mappings: rather than saying "a single c-char" 
as C++ does, the C standard says "a single character that
maps to a single-byte execution character"; WG14 fully expect
some (if not many or even most) UCNs to map to multiple characters.</P>

<P>Because of the fundamental differences between C and C++ character
types, I am not sure the C committee is qualified to answer this
satisfactorily for WG21.  WG14 is willing to review any decision reached
for compatibility.</P>

<P>I hope this helps.</P>
</BLOCKQUOTE>

<P>(See also <A HREF="
     cwg_defects.html#912">issue 912</A> for a related
question.)</P>

<BR><BR><HR><A NAME="1266"></A><H4>1266.
  
<I>user-defined-integer-literal</I> overflow
</H4><B>Section: </B>2.14.8&#160; [lex.ext]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-20<BR>


<P>The <I>decimal-literal</I> in a <I>user-defined-integer-literal</I>
might be too large for an <TT>unsigned long long</TT> to represent (in
implementations with extended integer types).  In such cases, the
original intent appears to have been to call a raw literal operator or
a literal operator template; however, the existing wording of
2.14.8 [lex.ext] paragraph 3 always calls the
<TT>unsigned long long</TT> literal operator if it exists, regardless
of the value of the <I>decimal-literal</I>.</P>

<BR><BR><HR><A NAME="1209"></A><H4>1209.
  
Is a potentially-evaluated expression in a template definition a &#8220;use?&#8221;
</H4><B>Section: </B>3.2&#160; [basic.def.odr]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2010-10-08<BR>




<P>Consider the following complete program:</P>

<PRE>
    void f();
    template&lt;typename T&gt; void g() { f(); }
    int main() { }
</PRE>

<P>Must <TT>f()</TT> be defined to make this program well-formed?  The
current wording of 3.2 [basic.def.odr] does not make any special
provision for expressions that appear only in uninstantiated template
definitions.</P>

(See also <A HREF="
     cwg_closed.html#1254">issue 1254</A>.)

<BR><BR><HR><A NAME="191"></A><H4>191.
  
Name lookup does not handle complex nesting
</H4><B>Section: </B>3.4.1&#160; [basic.lookup.unqual]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Alan Nash
 &#160;&#160;&#160;

 <B>Date: </B>29 Dec 1999<BR>





<P>The current description of unqualified name lookup in
3.4.1 [basic.lookup.unqual]
 paragraph 8 does
not correctly handle complex cases of nesting.  The Standard
currently reads,</P>

<BLOCKQUOTE>
A name used in the definition of a function that is a member function
(9.3) of a class <TT>X</TT> shall be declared in one of the following
ways:

<BR><UL>
<LI>before its use in the block in which it is used or in an enclosing
block (6.3), or</LI>

<LI>shall be a member of class <TT>X</TT> or be a member of a base
class of <TT>X</TT> (10.2), or</LI>

<LI>if <TT>X</TT> is a nested class of class <TT>Y</TT> (9.7), shall
be a member of <TT>Y</TT>, or shall be a member of a base class of
<TT>Y</TT> (this lookup applies in turn to <TT>Y</TT>'s enclosing
classes, starting with the innermost enclosing class), or</LI>

<LI>if <TT>X</TT> is a local class (9.8) or is a nested class of a
local class, before the definition of class <TT>X</TT> in a block
enclosing the definition of class <TT>X</TT>, or</LI>

<LI>if <TT>X</TT> is a member of namespace <TT>N</TT>, or is a nested
class of a class that is a member of <TT>N</TT>, or is a local class
or nested class within a local class of a function that is a member of
<TT>N</TT>, before the member function definition, in namespace
<TT>N</TT> or in one of <TT>N</TT>'s enclosing namespaces.</LI>
</UL>
</BLOCKQUOTE>

In particular, this formulation does not handle the following example:

<PRE>
    struct outer {
        static int i;
        struct inner {
            void f() {
                struct local {
                    void g() {
                        i = 5;
                    }
                };
            }
        };
    };
</PRE>

Here the reference to <TT>i</TT> is from a member function of a local
class of a member function of a nested class.  Nothing in the rules
allows <TT>outer::i</TT> to be found, although intuitively it should
be found.

<P>A more comprehensive formulation is needed that allows traversal of
any combination of blocks, local classes, and nested classes.
Similarly, the final bullet needs to be augmented so that a function
need not be a (direct) member of a namespace to allow searching that
namespace when the reference is from a member function of a class
local to that function.  That is, the current rules do not allow the
following example:</P>

<PRE>
    int j;    // global namespace
    struct S {
        void f() {
            struct local2 {
                void g() {
                    j = 5;
                }
            };
        }
    };
</PRE>
<BR><BR><HR><A NAME="405"></A><H4>405.
  
Unqualified function name lookup
</H4><B>Section: </B>3.4.1&#160; [basic.lookup.unqual]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>William M. Miller
 &#160;&#160;&#160;

 <B>Date: </B>14 Apr 2003<BR>


<P>There seems to be some confusion in the Standard regarding the
relationship between 3.4.1 [basic.lookup.unqual] (Unqualified name
lookup) and 3.4.2 [basic.lookup.argdep]
(Argument-dependent lookup).  For example,
3.4.1 [basic.lookup.unqual] paragraph 3 says,</P>

<BLOCKQUOTE>
The lookup for an unqualified name used as the
<I>postfix-expression</I> of a function call is described in
3.4.2 [basic.lookup.argdep].
</BLOCKQUOTE>

<P>In other words, nothing in 3.4.1 [basic.lookup.unqual]
applies to function names; the entire lookup is described in
3.4.2 [basic.lookup.argdep].</P>

<P>3.4.2 [basic.lookup.argdep] does not appear to share this
view of its responsibility.
The closest it comes is in 3.4.2 [basic.lookup.argdep] paragraph 2a:</P>

<BLOCKQUOTE>
...the set of declarations found by the lookup of the function
name is the union of the set of declarations found using ordinary
unqualified lookup and the set of declarations found in the namespaces
and classes associated with the argument types.
</BLOCKQUOTE>

<P>Presumably, "ordinary unqualified lookup" is a reference
to the processing described in
3.4.1 [basic.lookup.unqual], but, as noted above,
3.4.1 [basic.lookup.unqual]
explicitly precludes applying that processing to function names.  The
details of "ordinary unqualified lookup" of function names
are not described anywhere.</P>

<P>The other clauses that reference
3.4.2 [basic.lookup.argdep], clauses
13 [over] and 14 [temp], are
split over the question of the relationship between
3.4.1 [basic.lookup.unqual] and 3.4.2 [basic.lookup.argdep].
13.3.1.1.1 [over.call.func] paragraph 3, for instance, says</P>

<BLOCKQUOTE>
The name is looked up in the context of the function call
following the normal rules for name lookup in function calls
(3.4.2 [basic.lookup.argdep]).
</BLOCKQUOTE>

<P>I.e., this reference assumes that
3.4.2 [basic.lookup.argdep] is self-contained.  The
same is true of 13.3.1.2 [over.match.oper] paragraph 3,
second bullet:</P>

<BLOCKQUOTE>
The set of non-member candidates is the result of the
unqualified lookup of operator@ in the context of the expression
according to the usual rules for name lookup in unqualified function
calls (3.4.2 [basic.lookup.argdep]), except that all member
functions are ignored.
</BLOCKQUOTE>

<P>On the other hand, however, 14.6.4.2 [temp.dep.candidate]
paragraph 1 explicitly assumes that
3.4.1 [basic.lookup.unqual] and 3.4.2 [basic.lookup.argdep] are
both involved in function name lookup and do different things:</P>

<BLOCKQUOTE>
For a function call that depends on a template parameter, if
the function name is an <I>unqualified-id</I> but not a
<I>template-id</I>, the candidate functions are found using the usual
lookup rules (3.4.1 [basic.lookup.unqual],
3.4.2 [basic.lookup.argdep]) except that:
<UL>
<LI>For the part of the lookup using unqualified name lookup
(3.4.1 [basic.lookup.unqual]),
only function declarations with external linkage from the template
definition context are found.</LI>

<LI>For the part of the lookup using associated
namespaces (3.4.2 [basic.lookup.argdep]),
only function declarations with external linkage found in either the
template definition context or the template instantiation context are
found.</LI>
</UL>
</BLOCKQUOTE>

<B><P>Suggested resolution:</P></B>

<P>Change 3.4.1 [basic.lookup.unqual] paragraph 1 from</P>

<BLOCKQUOTE>
...name lookup ends as soon as a declaration is found for the
name.
</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>
...name lookup ends with the first scope containing one or more
declarations of the name.
</BLOCKQUOTE>

<P>Change the first sentence of 3.4.1 [basic.lookup.unqual]
paragraph 3 from</P>

<BLOCKQUOTE>
The lookup for an unqualified name used as the
<I>postfix-expression</I> of a function call is described in
3.4.2 [basic.lookup.argdep].
</BLOCKQUOTE>

<P>to</P>

<BLOCKQUOTE>
An unqualified name used as the <I>postfix-expression</I> of a
function call is looked up as described below.  In addition,
argument-dependent lookup (3.4.2 [basic.lookup.argdep]) is
performed on this name to
complete the resulting set of declarations.
</BLOCKQUOTE>



<BR><BR><HR><A NAME="1200"></A><H4>1200.
  
Lookup rules for template parameters
</H4><B>Section: </B>3.4.1&#160; [basic.lookup.unqual]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2010-09-18<BR>


<P>Although 3.3.9 [basic.scope.temp] now describes the scope of a
template parameter, the description of unqualified name lookup in
3.4.1 [basic.lookup.unqual] do not cover uses of template parameter
names.  The note in 3.4.1 [basic.lookup.unqual] paragraph 16 says,</P>

<BLOCKQUOTE>

the rules for name lookup in template definitions are described in
14.6 [temp.res].

</BLOCKQUOTE>

<P>but the rules there cover dependent and non-dependent names, not
template parameters themselves.</P>

<BR><BR><HR><A NAME="1753"></A><H4>1753.
  
<I>decltype-specifier</I> in <I>nested-name-specifier</I> of destructor
</H4><B>Section: </B>3.4.3&#160; [basic.lookup.qual]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-18<BR>


<P>One of the forms of <I>pseudo-destructor-name</I> is</P>

<UL><I>nested-name-specifier<SUB>opt</SUB></I> <TT>~</TT> <I>type-name</I></UL>

<P>Presumably the intent of this form is to allow
the <I>nested-name-specifier</I> to designate a namespace; otherwise
the</P>

<UL><I>nested-name-specifier<SUB>opt</SUB> type-name</I> <TT>:: ~</TT> <I>type-name</I></UL>

<P>production would be used.</P>

<P>Since one of the forms of <I>nested-name-specifier</I> is</P>

<UL><I>decltype-specifier</I> <TT>::</TT></UL>

<P>one can write something like <TT>p-&gt;decltype(x)::~Y()</TT>.
However, the lookup rules in 3.4.3 [basic.lookup.qual] paragraph 6 are
inappropriate for the <I>decltype-specifier</I> case:</P>

<BLOCKQUOTE>

If a <I>pseudo-destructor-name</I> (5.2.4 [expr.pseudo]) contains
a <I>nested-name-specifier</I>, the <I>type-name</I>s are looked up as
types in the scope designated by the <I>nested-name-specifier</I>.

</BLOCKQUOTE>

<P>Since this form appears to be useless (use of a <I>decltype-specifier</I>
is permitted after a <TT>~</TT>, but only with no
<I>nested-name-specifer</I> &#8212; but see
<A HREF="
     cwg_active.html#1586">issue 1586</A>), perhaps it should be made
ill-formed.</P>

<BR><BR><HR><A NAME="1771"></A><H4>1771.
  
Restricted lookup in <I>nested-name-specifier</I>
</H4><B>Section: </B>3.4.3&#160; [basic.lookup.qual]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Canada
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-24<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA21">N3690 comment
  CA&#160;21<BR></A>

<P>Consider the following example:</P>

<PRE>
  template &lt;typename T&gt; struct B { }; 
  namespace N { 
    namespace L { 
      template &lt;int&gt; void A(); 
    } 
    namespace M { 
      template &lt;int&gt; struct A { typedef int y; }; 
    } 
    using namespace L; 
    using namespace M; 
  } 
  B&lt;N::/*template */A&lt;0&gt;::y&gt; (x);
</PRE>

<P>Which <TT>A</TT> is referenced in the last line?  According to
3.4.3 [basic.lookup.qual] paragraph 1,</P>

<BLOCKQUOTE>

If a <TT>::</TT> scope resolution operator in
a <I>nested-name-specifier</I> is not preceded by
a <I>decltype-specifier</I>, lookup of the name preceding that
<TT>::</TT> considers only namespaces, types, and templates whose
specializations are types.

</BLOCKQUOTE>

<P>It is not clear whether this applies to the example or not,
and the interpretation of the <TT>&lt;</TT> token depends on the
result of the lookup.</P>

<P><B>Notes from the September, 2013 meeting:</B></P>

<P>The restricted lookup mentioned in 3.4.3 [basic.lookup.qual]
paragraph 1 is based on a one-token lookahead; because the next
token following <TT>A</TT> in the example is not <TT>::</TT>,
the restricted lookup does not apply, and the result is ambiguous.
Uncommenting the <TT>template</TT> keyword in the example does not
affect the lookup.</P>

<BR><BR><HR><A NAME="562"></A><H4>562.
  
<I>qualified-id</I>s in non-expression contexts
</H4><B>Section: </B>3.4.3.1&#160; [class.qual]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>6 April 2006<BR>


<P>Both 3.4.3.1 [class.qual] and 3.4.3.2 [namespace.qual]
specify that some lookups are to be performed &#8220;in the context of the
entire <I>postfix-expression</I>,&#8221; ignoring the fact that
<I>qualified-id</I>s can appear outside of expressions.</P>

<P>It was suggested in document J16/05-0156 = WG21 N1896 that these
uses be changed to &#8220;the context in which the <I>qualified-id</I>
occurs,&#8221; but it isn't clear that this formulation adequately
covers all the places a <I>qualified-id</I> can occur.</P>

<BR><BR><HR><A NAME="278"></A><H4>278.
  
External linkage and nameless entities
</H4><B>Section: </B>3.5&#160; [basic.link]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>12 Apr 2000<BR>




<P>It is unclear to what extent entities without names match
across translation units.  For example,</P>

<PRE>
    struct S {
       int :2;
       enum { a, b, c } x;
       static class {} *p;
    };
</PRE>

<P>If this declaration appears in multiple translation units, are
all these members "the same" in each declaration?</P>

<P>A similar question can be asked about non-member declarations:</P>

<PRE>
    // Translation unit 1:
    extern enum { d, e, f } y;

    // Translation unit 2:
    extern enum { d, e, f } y;

    // Translation unit 3:
    enum { d, e, f } y;
</PRE>

<P>Is this valid C++?  Is it valid C?</P>

<P><U>James Kanze</U>: <TT>S::p</TT> cannot be defined, because to
do so requires a type specifier and the type cannot be named.
<TT>::y</TT> is valid C because C only requires compatible, not
identical, types.  In C++, it appears that there is a new type in
each declaration, so it would not be valid.  This differs from
<TT>S::x</TT> because the unnamed type is part of a named type
&#8212; but I don't know where or if the Standard says that.</P>

<P><U>John Max Skaller</U>:
It's not valid C++, because the type is a synthesised, unique name
for the enumeration type which differs across translation units, as if:</P>

<PRE>
    extern enum _synth1 { d,e,f} y;
    ..
    extern enum _synth2 { d,e,f} y;
</PRE>

<P>had been written.</P>

<P>However, within a class, the ODR implies the types are the same:</P>

<PRE>
    class X { enum { d } y; };
</PRE>

<P>in two translation units ensures that the type of member <TT>y</TT>
is the same: the two <TT>X</TT>'s obey the ODR and so denote the same class,
and it follows that there's only one member <TT>y</TT> and one type that it
has.</P>

<P>(See also issues <A HREF="
     cwg_closed.html#132">132</A> and
<A HREF="
     cwg_defects.html#216">216</A>.)</P>

<BR><BR><HR><A NAME="279"></A><H4>279.
  
Correspondence of "names for linkage purposes"
</H4><B>Section: </B>3.5&#160; [basic.link]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>4 Apr 2001<BR>




<P>The standard says that an unnamed class or enum definition can be given
a "name for linkage purposes" through a typedef.  E.g.,</P>

<PRE>
    typedef enum {} E;
    extern E *p;
</PRE>

<P>can appear in multiple translation units.</P>

<P>How about the following combination?</P>

<PRE>
    // Translation unit 1:
    struct S;
    extern S *q;

    // Translation unit 2:
    typedef struct {} S;
    extern S *q;
</PRE>

<P>Is this valid C++?</P>

<P>Also, if the answer is "yes", consider the following slight variant:</P>

<PRE>
    // Translation unit 1:
    struct S {};  // &lt;&lt;-- class has definition
    extern S *q;

    // Translation unit 2:
    typedef struct {} S;
    extern S *q;
</PRE>

<P>Is this a violation of the ODR because two definitions
of type <TT>S</TT> consist of differing token sequences?</P>

<BR><BR><HR><A NAME="338"></A><H4>338.
  
Enumerator name with linkage used as class name in other translation unit
</H4><B>Section: </B>3.5&#160; [basic.link]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>26 Feb 2002<BR>




<P>The following declarations are allowed within a translation
unit:</P>
<PRE>
  struct S;
  enum { S };
</PRE>
<P>However, 3.5 [basic.link] paragraph 9 seems to say
these two declarations
cannot appear in two different translation units.  That also
would mean that the inclusion of a header containing the above
in two different translation units is not valid C++.</P>

<P>I suspect this is an oversight and that users should be allowed
to have the declarations above appear in different translation
units.  (It is a fairly common thing to do, I think.)</P>

<P><U>Mike Miller</U>:
I think you meant "<TT>enum E { S };</TT>" -- enumerators only have
external linkage if the enumeration does (3.5 [basic.link]
paragraph 4), and 3.5 [basic.link] paragraph 9 only
applies to entities with external linkage.</P>

<P>I don't remember why enumerators were given linkage; I don't
think it's necessary for mangling non-type template arguments.
In any event, I can't think why cross-TU name collisions between
enumerators and other entities would cause a problem, so I guess
a change here would be okay.  I can think of three changes that
would have that effect:</P>

<OL>
<LI>
Saying that enumerators do not have linkage.
</LI>
<LI>
Removing enumerators from the list of entities in the first
sentence of 3.5 [basic.link] paragraph 9.
</LI>
<LI>
Saying that it's okay for an enumerator in one TU to have the
same name as a class type in another TU only if the enumerator
hides that same class type in both TUs (the example you gave).
</LI>
</OL>

<P><U>Daveed Vandevoorde</U>:
I don't think any of these are sufficient in the sense that the problem
isn't limited to enumerators.  E.g.:
<PRE>
  struct X;
  extern void X();
</PRE>
shouldn't create cross-TU collisions either.</P>

<P><U>Mike Miller</U>:
So you're saying that cross-TU collisions should only be
prohibited if both names denote entities of the same kind (both
functions, both objects, both types, etc.), or if they are both
references (regardless of what they refer to, presumably)?</P>

<P><U>Daveed Vandevoorde</U>:
Not exactly.  Instead, I'm saying that if two entities (with
external linkage) can coexist when they're both declared in the
same translation unit (TU), then they should also be allowed to
coexist when they're declared in two different translation units.</P>

<P>For example:
<PRE>
  int i;
  void i();  // Error
</PRE>
This is an error within a TU, so I don't see a reason to make it
valid across TUs.</P>

<P>However, "tag names" (class/struct/union/enum) can sometimes
coexist with identically named entities (variables, functions &amp;
enumerators, but not namespaces, templates or type names).</P>

<BR><BR><HR><A NAME="371"></A><H4>371.
  
Interleaving of constructor calls
</H4><B>Section: </B>3.6.2&#160; [basic.start.init]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Matt Austern
 &#160;&#160;&#160;

 <B>Date: </B>7 August 2002<BR>




<P>Is a compiler allowed to interleave constructor calls when
performing dynamic initialization of nonlocal objects?
What I mean by interleaving is: beginning to execute a
particular constructor, then going off and doing
something else, then going back to the original constructor.
I can't find anything explicit about this in clause
3.6.2 [basic.start.init].</P>

<P>I'll present a few different examples, some of which get a
bit wild.  But a lot of what this comes down to is exactly
what the standard means when it talks about the order
of initialization.  If it says that some object x must be
initialized before a particular event takes place, does that
mean that x's constructor must be entered before that
event, or does it mean that it must be exited before that
event?  If object x must be initialized before object y,
does that mean that x's constructor must exit before y's
constructor is entered?</P>

<P>(The answer to that question might just be common sense,
but I couldn't find an answer in clause 3.6.2 [basic.start.init].
Actually, when I read 3.6.2 [basic.start.init]
carefully, I find there are a lot of things I took
for granted that aren't there.)</P>

<P>OK, so a few specific scenerios.</P>
<OL>
<LI>We have a translation unit with nonlocal objects A and B,
both of which require dynamic initialization.  A comes before
B.  A must be initialized before B.  May the compiler start
to construct A, get partway through the constructor, then
construct B, and then go back to finishing A?</LI>

<LI>We have a translation unit with nonlocal object A and
function f.  Construction of A is deferred until after the
first statement of main.  A must be constructed before the
first use of f.  Is the compiler permitted to start constructing
A, then execute f, then go back to constructing A?</LI>

<LI>We have nonlocal objects A and B, in two different
translation units.  The order in which A and B are constructed
is unspecified by the Standard.  Is the compiler permitted to
begin constructing A, then construct B, then finish A's
constructor?  Note the implications of a 'yes' answer.  If A's
and B's constructor both call some function f, then the call
stack might look like this:
<PRE>
   &lt;runtime gunk&gt;
     &lt;Enter A's constructor&gt;
        &lt;Enter f&gt;
           &lt;runtime gunk&gt;
              &lt;Enter B's constructor&gt;
                 &lt;Enter f&gt;
                 &lt;Leave f&gt;
              &lt;Leave B's constructor&gt;
        &lt;Leave f&gt;
     &lt;Leave A's constructor&gt;
</PRE>
The implication of a 'yes' answer for users is that any function
called by a constructor, directly or indirectly, must be reentrant.</LI>

<LI>This last example is to show why a 'no' answer to #3 might
be a problem too.  New scenerio: we've got one translation
unit containing a nonlocal object A and a function f1, and another
translation unit containing a nonlocal object B and a function f2.
A's constructor calls f2.  Initialization of A and B is deferred until
after the first statement of main().  Someone in main calls f1.
Question: is the compiler permitted to start constructing A, then
go off and construct B at some point before f2 gets called, then
go back and finish constructing A?  In fact, is the compiler
required to do that?  We've got an unpleasant tension here between
the bad implications of a 'yes' answer to #3, and the explicit
requirement in 3.6.2 [basic.start.init] paragraph 3.</LI>
</OL>

<P>At this point, you might be thinking we could avoid all of this
nonsense by removing compilers' freedom to defer initialization
until after the beginning of main().  I'd resist that, for two reasons.
First, it would be a huge change to make after the standard has
been out.  Second, that freedom is necessary if we want to have
support for dynamic libraries.  I realize we don't yet say anything
about dynamic libraries, but I'd hate to make decisions that would
make such support even harder.</P>

<BR><BR><HR><A NAME="1659"></A><H4>1659.
  
Initialization order of thread_local template static data members
</H4><B>Section: </B>3.6.2&#160; [basic.start.init]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-14<BR>


<P>According to 3.6.2 [basic.start.init] paragraph 5,</P>

<BLOCKQUOTE>

It is implementation-defined whether the dynamic initialization of a
non-local variable with static or thread storage duration is done before
the first statement of the initial function of the thread. If the
initialization is deferred to some point in time after the first statement
of the initial function of the thread, it shall occur before the first
odr-use (3.2 [basic.def.odr]) of any variable with thread storage
duration defined in the same translation unit as the variable to be
initialized.

</BLOCKQUOTE>

<P>This doesn't consider that initialization of instantiations of static
data members of class templates (which can be <TT>thread_local</TT>) are
unordered.  Presumably odr-use of such a static data member should not
trigger the initialization of any <TT>thread_local</TT> variable other than
that one?</P>

<BR><BR><HR><A NAME="1744"></A><H4>1744.
  
Unordered initialization for variable template specializations
</H4><B>Section: </B>3.6.2&#160; [basic.start.init]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-03<BR>




<P>According to 3.6.2 [basic.start.init] paragraph 2,</P>

<BLOCKQUOTE>

Definitions of explicitly specialized class template static data members
have ordered initialization. Other class template static data members
(i.e., implicitly or explicitly instantiated specializations) have
unordered initialization.

</BLOCKQUOTE>

<P>This is not clear whether it is referring to static data members of
explicit specializations of class templates or to explicit specializations
of static data members of class template specializations.  It also does
not apply to static data member templates and non-member variable
templates.</P>

<P><U>Suggested resolution:</U></P>

<P>Change 3.6.2 [basic.start.init] paragraph 2 as follows:</P>

<BLOCKQUOTE>

...Dynamic initialization of a non-local variable with static storage duration
is <SPAN style="text-decoration:line-through;background-color:#FFA0A0">either ordered or unordered. Definitions of explicitly specialized
class template static data members have ordered initializa-tion. Other
class template static data members (i.e., implicitly or explicitly
instantiated specializations) have unordered initialization. Other
non-local variables with static storage duration have ordered
initialization</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0"><I>unordered</I> if the variable is an implicitly
or explicitly instantiated specialization, and otherwise is
<I>ordered</I> [<I>Note:</I> an explicitly specialized static data member
or variable template specialization has ordered initialization.
&#8212;<I>end note</I>]</SPAN>.  Variables with ordered initialization...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1747"></A><H4>1747.
  
Constant initialization of reference to function
</H4><B>Section: </B>3.6.2&#160; [basic.start.init]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-10<BR>




<P>According to 3.6.2 [basic.start.init] paragaph 2,</P>

<BLOCKQUOTE>

<P>...<I>Constant initialization</I> is performed:</P>

<UL><LI><P>if each full-expression (including implicit conversions) that
appears in the initializer of a reference with static or thread storage
duration is a constant expression (5.19 [expr.const]) and the
reference is bound to an lvalue designating an object with static storage
duration or to a temporary (see 12.2 [class.temporary]);</P></LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<P>This wording, presumably inadvertently, excludes a reference to a
function from being constant initialization.</P>

<BR><BR><HR><A NAME="1749"></A><H4>1749.
  
Confusing definition for constant initializer
</H4><B>Section: </B>3.6.2&#160; [basic.start.init]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-12<BR>


<P>According to 3.6.2 [basic.start.init] paragraph 2,</P>

<BLOCKQUOTE>

A <I>constant initializer</I> for an object <TT>o</TT> is an expression
that is a constant expression, except that it may also
invoke <TT>constexpr</TT> constructors for <TT>o</TT> and its subobjects
even if those objects are of non-literal class types [<I>Note:</I> such a
class may have a non-trivial destructor &#8212;<I>end note</I>].

</BLOCKQUOTE>

<P>This would be clearer if worded as something like,</P>

<BLOCKQUOTE>

A <I>constant initializer</I> for an object <TT>o</TT> is an expression
that would be a constant expression if every <TT>constexpr</TT> constructor
invoked for <TT>o</TT> and its subobjects were a constructor for a literal
class type.

</BLOCKQUOTE>

<BR><BR><HR><A NAME="640"></A><H4>640.
  
Accessing destroyed local objects of static storage duration
</H4><B>Section: </B>3.6.3&#160; [basic.start.term]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Howard Hinnant
 &#160;&#160;&#160;

 <B>Date: </B>30 July 2007<BR>




<P>3.6.3 [basic.start.term] paragraph 2 says,</P>

<BLOCKQUOTE>

If a function contains a local object of static storage duration
that has been destroyed and the function is called during the
destruction of an object with static storage duration, the
program has undefined behavior if the flow of control passes
through the definition of the previously destroyed local object.

</BLOCKQUOTE>

<P>I would like to turn this behavior from undefined to
well-defined behavior for the purpose of achieving a graceful
shutdown, especially in a multi-threaded world.</P>

<P>Background: Alexandrescu describes the &#8220;phoenix
singleton&#8221; in <I>Modern C++ Design</I>.  This is a class
used as a function local static, that will reconstruct itself,
and reapply itself to the <TT>atexit</TT> chain, if the program
attempts to use it after it is destructed in the <TT>atexit</TT>
chain.  It achieves this by setting a &#8220;destructed
flag&#8221; in its own state in its destructor.  If the object is
later accessed (and a member function is called on it), the
member function notes the state of the &#8220;destructed
flag&#8221; and does the reconstruction dance.  The phoenix
singleton pattern was designed to address issues only in
single-threaded code where accesses among static objects can have
a non-scoped pattern.  When we throw in multi-threading, and the
possibility that threads can be running after <TT>main</TT>
returns, the chances of accessing a destroyed static
significantly increase.</P>

<P>The very least that I would like to see happen is to standardize what  
I believe is existing practice:  When an object is destroyed in the  
<TT>atexit</TT> chain, the memory the object occupied is left in
whatever state the destructor put it in.  If this can only be
reliably done for objects with standard layout, that would be an
acceptable compromise.  This would allow objects to set &#8220;I'm
destructed&#8221; flags in their state and then do something
well-defined if accessed, such as throw an exception.</P>

<P>A possible refinement of this idea is to have the compiler set
up a 3-state flag around function-local statics instead of the
current 2-state flag:</P>

<UL>
<LI>Not constructed yet</LI>
<LI>Constructed but not destroyed yet</LI>
<LI>Destroyed</LI>
</UL>

<P>We have the first two states today.  We might choose to add
the third state, and if execution passes over a function-local
static with &#8220;destroyed&#8221; state, an exception could be
thrown.  This would mean that we would not have to guarantee
memory stability in destroyed objects of static duration.</P>

<P>This refinement would break phoenix singletons, and is not
required for the <TT>~mutex()</TT>/<TT>~condition()</TT> I've
described and prototyped.  But it might make it easier for Joe
Coder to apply this kind of guarantee to his own types.</P>

<BR><BR><HR><A NAME="365"></A><H4>365.
  
Storage duration and temporaries
</H4><B>Section: </B>3.7&#160; [basic.stc]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>James Kanze
 &#160;&#160;&#160;

 <B>Date: </B>24 July 2002<BR>


<P>There are several problems with 3.7 [basic.stc]:</P>
<UL>
<LI>
<P>3.7 [basic.stc] paragraph 2 says that "Static and automatic
storage durations are associated with objects introduced by
declarations (3.1 [basic.def]) and implicitly created
by the implementation (12.2 [class.temporary])."</P>

<P>In fact, objects "implicitly created by the implementation" are the
temporaries described in (12.2 [class.temporary]), and have neither
static nor automatic storage duration, but a totally different duration,
described in 12.2 [class.temporary].</P>
</LI>
<LI>
<P>3.7 [basic.stc] uses the expression "local object" in several 
places, without ever defining it.  Presumably, what is meant is "an 
object declared at block scope", but this should be said explicitly.</P>

<P>In a recent discussion in comp.lang.c++.moderated, on poster 
interpreted "local objects" as including temporaries.  This would require them 
to live until the end of the block in which they are created, which
contradicts 12.2 [class.temporary]. If temporaries are covered by
this section, and the statement in 3.7 [basic.stc]
seems to suggest, and they aren't local objects, then they must have
static storage duration, which isn't right either.</P>

<P>I propose adding a fourth storage duration to the list after
3.7 [basic.stc] paragraph 1:</P>
<UL>
<LI>
temporary storage duration
</LI>
</UL>
<P>And rewriting the second paragraph of this section as follows:</P>
<BLOCKQUOTE>
Temporary storage duration is associated with objects implicitly
created by the implementation, and is described in 12.2 [class.temporary].
Static and automatic storage durations are associated with objects defined
by declarations; in the following, an object defined by a declaration
with block scope is a local object.  The dynamic storage duration is
associated with objects created by the <TT>operator new</TT>.
</BLOCKQUOTE>
</LI>
</UL>

<P><U>Steve Adamczyk</U>:
There may well be an issue here, but one should bear in mind the
difference between storage duration and object lifetime.  As far
as I can see, there is no particular problem with temporaries having
automatic or static storage duration, as appropriate.  The point
of 12.2 [class.temporary] is that they have an unusual object
lifetime.</P>

<P><B>Notes from Ocrober 2002 meeting:</B></P>

<P>It might be desirable to shorten the storage duration of temporaries
to allow reuse of them.  The as-if rule allows some reuse, but such
reuse requires analysis, including noting whether the addresses of
such temporaries have been taken.</P>

<P><B>Notes from the August, 2011 meeting:</B></P>

<P>The CWG decided that further consideration of this issue would be
deferred until someone produces a paper explaining the need for action
and proposing specific changes.</P>

<BR><BR><HR><A NAME="967"></A><H4>967.
  
Exception specification of replacement allocation function
</H4><B>Section: </B>3.7.4&#160; [basic.stc.dynamic]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Clamage
 &#160;&#160;&#160;

 <B>Date: </B>15 September, 2009<BR>




<P>The global allocation functions are implicitly declared in every
translation unit with <I>exception-specification</I>s
(3.7.4 [basic.stc.dynamic] paragraph 2).  It is not clear what
should happen if a replacement allocation function is declared without
an <I>exception-specification</I>.  Is that a conflict with the
implicitly-declared function (as it would be with explicitly-declared
functions, and presumably is if the <TT>&lt;new&gt;</TT> header is
included)?  Or does the new declaration replace the implicit one,
including the lack of an <I>exception-specification</I>?  Or does the
implicit declaration prevail?  (Regardless of the
<I>exception-specification</I> or lack thereof, it is presumably
undefined behavior for an allocation function to exit with an
exception that cannot be caught by a handler of type
<TT>std::bad_alloc</TT> (3.7.4.1 [basic.stc.dynamic.allocation] paragraph
3).)</P>

<BR><BR><HR><A NAME="1682"></A><H4>1682.
  
Overly-restrictive rules on function templates as allocation functions
</H4><B>Section: </B>3.7.4.1&#160; [basic.stc.dynamic.allocation]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2009-03-03<BR>




<P>Requirements for allocation functions are given in
3.7.4.1 [basic.stc.dynamic.allocation] paragraph 1:</P>

<BLOCKQUOTE>

An allocation function can be a function template. Such a template shall
declare its return type and first parameter as specified above (that is,
template parameter types shall not be used in the return type and first
parameter type). Template allocation functions shall have two or more
parameters.

</BLOCKQUOTE>

<P>There are a couple of problems with this description.  First, it is
instances of function templates that can be allocation functions, not
the templates themselves (cf 3.7.4.2 [basic.stc.dynamic.deallocation] paragraph 2,
which uses the correct terminology regarding deallocation functions).</P>

<P>More importantly, this specification was written before template
metaprogramming was understood and hence prevents use of SFINAE on the
return type or parameter type to select among function template
specializations.  (The parallel passage for deallocation functions in
3.7.4.2 [basic.stc.dynamic.deallocation] paragraph 2 shares this deficit.)</P>



<P>(See also <A HREF="
     cwg_active.html#1628">issue 1628</A>.)</P>

<BR><BR><HR><A NAME="523"></A><H4>523.
  
Can a one-past-the-end pointer be invalidated by deleting an adjacent object?
</H4><B>Section: </B>3.7.4.2&#160; [basic.stc.dynamic.deallocation]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>comp.std.c++
 &#160;&#160;&#160;

 <B>Date: </B>8 July 2005<BR>


<P>When an object is deleted, 3.7.4.2 [basic.stc.dynamic.deallocation] says
that the deallocation &#8220;[renders] invalid all pointers referring
to any part of the deallocated storage.&#8221; According to
3.9.2 [basic.compound] paragraph 3, a pointer whose address is
one past the end of an array is considered to point to an unrelated
object that happens to reside at that address.  Does this need to be
clarified to specify that the one-past-the-end pointer of an array is
not invalidated by deleting the following object?  (See also
5.3.5 [expr.delete] paragraph 4, which also mentions that
the system deallocation function renders a pointer invalid.)</P>

<BR><BR><HR><A NAME="419"></A><H4>419.
  
Can cast to virtual base class be done on partially-constructed object?
</H4><B>Section: </B>3.8&#160; [basic.life]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Judy Ward
 &#160;&#160;&#160;

 <B>Date: </B>2 June 2003<BR>


<P>Consider</P>
<PRE>
  extern "C" int printf (const char *,...);

  struct Base { Base();};
  struct Derived: virtual public Base {
     Derived() {;}
  };

  Derived d;
  extern Derived&amp; obj = d;

  int i;

  Base::Base() {
    if ((Base *) &amp;obj) i = 4;
    printf ("i=%d\n", i);
  }

  int main() { return 0; }
</PRE>

<P>12.7 [class.cdtor] paragraph 2 makes this valid, but
3.8 [basic.life] paragraph 5 implies that it isn't valid.</P>

<P><U>Steve Adamczyk:</U>
A second issue:</P>
<PRE>
  extern "C" int printf(const char *,...);
  struct A                      { virtual ~A(); int x; };
  struct B : public virtual A   { };
  struct C : public B           { C(int); };
  struct D : public C           { D(); };
 
  int main()                    { D t; printf("passed\n");return 0; }
 
  A::~A()                       {} 
  C::C(int)                     {} 
  D::D() : C(this-&gt;x)           {}
</PRE>
<P><A HREF="
     cwg_defects.html#52">Core issue 52</A> almost, but not quite,
says that in evaluating "this-&gt;x"
you do a cast to the virtual base class A, which would be an error
according to 12.7 [class.cdtor] paragraph 2 because the base
class B constructor hasn't started yet.
5.2.5 [expr.ref] should be clarified to say that
the cast does need to get done.</P>

<P><U>James Kanze</U> submitted the same issue via comp.std.c++
on 11 July 2003:</P>
<BLOCKQUOTE>
Richard Smith:
Nonsense. You can use "this" perfectly happily in a constructor, just
be careful that (a) you're not using any members that are not fully
initialised, and (b) if you're calling virtual functions you know
exactly what you're doing.
</BLOCKQUOTE>

<P>In practice, and I think in intent, you are right.  However, the
standard makes some pretty stringent restrictions in
3.8 [basic.life].  To start
with, it says (in paragraph 1): </P>
<BLOCKQUOTE>
    The lifetime of an object is a runtime property of the object.  The
    lifetime of an object of type T begins when:
<UL>
<LI>
        storage with the proper alignment and size for type T is
        obtained, and
</LI>
<LI>

        if T is a class type with a non-trivial constructor, the
        constructor calls has COMPLETED.
</LI>
</UL>
    The lifetime of an object of type T ends when:
<UL>
<LI>
        if T is a class type with a non-trivial destructor, the
        destructor call STARTS, or
</LI>
<LI>
        the storage which the object occupies is reused or released.
</LI>
</UL>
</BLOCKQUOTE>
(Emphasis added.)  Then when we get down to paragraph 5, it says:
<BLOCKQUOTE>
<P>
    Before the lifetime of an object has started but after the storage
    which the object will occupy has been allocated [which sounds to me
    like it would include in the constructor, given the text above] or,
    after the lifetime of an object has ended and before the storage
    which the object occupied is reused or released, any pointer that
    refers to the storage location where the object will be or was
    located may be used but only in limited ways. [...] If the object
    will be or was of a non-POD class type, the program has undefined
    behavior if:
</P>
<P>
    [...]
</P>
<UL>
<LI>
        the pointer is implicitly converted to a pointer to a base class
        type, or [...]
</LI>
</UL>
</BLOCKQUOTE>

<P>I can't find any exceptions for the this pointer.</P>

<P>Note that calling a non-static function in the base class, or even
constructing the base class in initializer list, involves an implicit
conversion of this to a pointer to the base class.  Thus undefined
behavior.  I'm sure that this wasn't the intent, but it would seem to be
what this paragraph is saying.</P>

<BR><BR><HR><A NAME="1285"></A><H4>1285.
  
Trivial destructors and object lifetime
</H4><B>Section: </B>3.8&#160; [basic.life]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2011-04-02<BR>




<P>The Standard is self-contradictory regarding which destructor calls
end the lifetime of an object.  3.8 [basic.life] paragraph 1
says,</P>

<BLOCKQUOTE>

<P>The lifetime of an object of type T ends when:</P>

<UL><LI><P>if <TT>T</TT> is a class type with a non-trivial destructor
(12.4 [class.dtor]), the destructor call starts, or
</P></LI>

<LI><P>the storage which the object occupies is reused or released.
</P></LI>

</UL>

</BLOCKQUOTE>

<P>i.e., the lifetime of an object of a class type with a
trivial destructor persists until its storage is reused or released.
However, 12.4 [class.dtor] paragraph 15 says,</P>

<BLOCKQUOTE>

Once a destructor is invoked for an object, the object no longer
exists; the behavior is undefined if the destructor is invoked for an
object whose lifetime has ended (3.8 [basic.life]).

</BLOCKQUOTE>

<P>implying that invoking any destructor, even a trivial one, ends
the lifetime of the associated object.  Similarly, 12.7 [class.cdtor]
paragraph 1 says,</P>

<BLOCKQUOTE>

For an object with a non-trivial destructor, referring to any
non-static member or base class of the object after the destructor
finishes execution results in undefined behavior.

</BLOCKQUOTE>

<P>A similar question arises for
pseudo-destructors for non-class types.</P>

<P><B>Notes from the August, 2011 meeting:</B></P>

<P>CWG will need a paper exploring this topic before it can act on
the issue.</P>

<BR><BR><HR><A NAME="1751"></A><H4>1751.
  
Non-trivial operations vs non-trivial initialization
</H4><B>Section: </B>3.8&#160; [basic.life]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Nico Josuttis
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-15<BR>




<P>The description of <TT>is_trivially_constructible</TT> in
20.11.4.3 [meta.unary.prop] paragraph 3 says,</P>

<BLOCKQUOTE>

<TT>is_constructible&lt;T, Args...&gt;::value</TT> is <TT>true</TT> and the
variable definition for <TT>is_constructible</TT>, as defined below, is
known to call no operation that is not trivial ( 3.9 [basic.types],
12 [special]).

</BLOCKQUOTE>

<P>This risks confusion when compared with the wording in
3.8 [basic.life] paragraph 1,</P>

<BLOCKQUOTE>

An object is said to have non-trivial initialization if it is of a class or
aggregate type and it or one of its members is initialized by a constructor
other than a trivial default constructor. [<I>Note:</I> initialization by a
trivial copy/move constructor is non-trivial initialization. &#8212;<I>end
note</I>]

</BLOCKQUOTE>

<P>The latter was written long before &#8220;trivial&#8221; became an
important concept in its own right and uses the term differently from
how it is used elsewhere in the Standard (as evidenced by the note
referring to copy/move construction).  The intent is to capture the
idea that there is some actual initialization occurring; it should
be rephrased to avoid the potential of confusion with the usage of
&#8220;trivial&#8221; elsewhere.</P>

<BR><BR><HR><A NAME="1776"></A><H4>1776.
  
Replacement of class objects containing reference members
</H4><B>Section: </B>3.8&#160; [basic.life]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Finland
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-24<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#FI15">N3690 comment
  FI&#160;15<BR></A>

<p>The rules given in 3.8 [basic.life] paragraph 7 for when
an object's lifetime can be ended and a new object created in its
storage include the following restriction:</p>

<BLOCKQUOTE>

the type of the original object is not const-qualified, and, if a class
type, does not contain any non-static data member whose type is
const-qualified or a reference type

</BLOCKQUOTE>

<P>The intent of this restriction is to permit optimizers to rely upon
the original values of <TT>const</TT> and reference members in their
analysis of subsequent code.  However, this makes it difficult to
implement certain desirable functionality such as
<TT>optional&lt;T&gt;</TT>; see
<A HREF="https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/93ebFsxCjvQ/myxPG6o_9pkJ">this discussion</A>
for more details.</P>

<P>This rule should be reconsidered, at least as far as it applies to
unions.  If it is decided to keep the rule, acceptable programming
techniques for writing safe code when replacing such objects should
be outlined in a note.</P>

<P>(See also <A HREF="
     cwg_active.html#1404">issue 1404</A>, which will become
moot if the restriction is lifted.)</P>

<BR><BR><HR><A NAME="350"></A><H4>350.
  
<TT>signed char</TT> underlying representation for objects
</H4><B>Section: </B>3.9&#160; [basic.types]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Noah Stein
 &#160;&#160;&#160;

 <B>Date: </B>16 April 2002<BR>


<P>Sent in by David Abrahams:</P>

<P>Yes, and to add to this tangent, 3.9.1 [basic.fundamental]
paragraph 1 states "Plain char, signed char, and unsigned char are
three distinct types."  Strangely, 3.9 [basic.types]
paragraph 2 talks about how "... the underlying bytes making up
the object can be copied into an array of char or unsigned char.
If the content of the array of char or unsigned char is copied back
into the object, the object shall subsequently hold its original
value."  I guess there's no requirement that this copying
work properly with signed chars!</P>

<P><B>Notes from October 2002 meeting:</B></P>

<P>We should do whatever C99 does.  6.5p6 of the C99 standard says
"array of character type", and "character type" includes signed
char (6.2.5p15), and 6.5p7 says "character type".
But see also 6.2.6.1p4, which mentions (only) an array of unsigned char.</P>

<P><B>Proposed resolution (April 2003):</B></P>

<P>Change 3.8 [basic.life] paragraph 5 bullet 3 from</P>

<UL><LI>
the pointer is used as the operand of a
<TT>static_cast</TT>
(5.2.9 [expr.static.cast])
(except when the conversion is to
<TT>void*</TT>,
or to
<TT>void*</TT>
and subsequently to
<TT>char*</TT>,
or
<TT>unsigned</TT>
<TT>char*</TT>).
</LI>
</UL>

<P>to</P>

<UL><LI>
the pointer is used as the operand of a
<TT>static_cast</TT>
(5.2.9 [expr.static.cast])
(except when the conversion is to
<TT>void*</TT>,
or to
<TT>void*</TT>
and subsequently to a pointer to byte-character type).
</LI>
</UL>

<P>Change 3.8 [basic.life] paragraph 6 bullet 3 from </P>
<UL><LI>
the lvalue is used as the operand of a
<TT>static_cast</TT>
(5.2.9 [expr.static.cast])
(except when the conversion is ultimately to
<TT>char&amp;</TT>
or
<TT>unsigned</TT>
<TT>char&amp;</TT>),
or
</LI>
</UL>
<P>to</P>
<UL><LI>
the lvalue is used as the operand of a
<TT>static_cast</TT>
(5.2.9 [expr.static.cast])
(except when the conversion is ultimately to a reference to
byte-character type),
or
</LI>
</UL>

<P>Change the beginning of 3.9 [basic.types] paragraph 2 from</P>
<BLOCKQUOTE>
For any object (other than a base-class subobject) of POD type
<TT>T</TT>,
whether or not the object holds a valid value of type
<TT>T</TT>,
the underlying bytes (1.7 [intro.memory])
making up the object can be copied
into an array of
<TT>char</TT>
or
<TT>unsigned</TT>
<TT>char</TT>.
</BLOCKQUOTE>
<P>to</P>
<BLOCKQUOTE>
For any object (other than a base-class subobject) of POD type
<TT>T</TT>,
whether or not the object holds a valid value of type
<TT>T</TT>,
the underlying bytes (1.7 [intro.memory])
making up the object can be copied
into an array of byte-character type.
</BLOCKQUOTE>

<P>Add the indicated text to 3.9.1 [basic.fundamental] paragraph 1:</P>

<BLOCKQUOTE>
Objects declared as characters
(<TT>char</TT>)
shall be large enough to store any member of
the implementation's basic character set.
If a character from this set is stored in a character object,
the integral value of that character object
is equal to
the value of the single character literal form of that character.
It is implementation-defined whether a
<TT>char</TT>
object can hold negative values.
Characters can be explicitly declared
<TT>unsigned</TT>
or
<TT>signed</TT>.
Plain
<TT>char</TT>,
<TT>signed char</TT>,
and
<TT>unsigned char</TT>
are three distinct types<SPAN style="font-weight:bold;background-color:#A0FFA0">, called the <I>byte-character types</I></SPAN>.
A
<TT>char</TT>,
a
<TT>signed char</TT>,
and an
<TT>unsigned char</TT>
occupy the same amount of storage and have the same alignment requirements
(3.9 [basic.types]); that is, they have the
same object representation.
For <SPAN style="font-weight:bold;background-color:#A0FFA0">byte-</SPAN>character types, all bits of the object representation participate in
the value representation.
For unsigned <SPAN style="font-weight:bold;background-color:#A0FFA0">byte-</SPAN>character types, all possible bit
patterns of the value representation represent numbers.
These requirements
do not hold for other types.
In any particular implementation, a plain
<TT>char</TT>
object can take on either the same values as a
<TT>signed char</TT>
or an
<TT>unsigned char</TT>;
which one is implementation-defined.
</BLOCKQUOTE>

<P>Change 3.10 [basic.lval] paragraph 15 last bullet from</P>
<UL><LI>
a
<TT>char</TT>
or
<TT>unsigned</TT>
<TT>char</TT>
type.
</LI>
</UL>
<P>to</P>
<UL><LI>
a byte-character type.
</LI>
</UL>

<P><B>Notes from October 2003 meeting:</B></P>

<P>It appears that in C99 signed char may have padding bits but no trap
representation, whereas in C++ signed char has no padding bits but
may have -0.  A memcpy in C++ would have to copy the array preserving
the actual representation and not just the value.</P>

<P>March 2004: The liaisons to the C committee have been asked to tell us
whether this change would introduce any unnecessary incompatibilities
with C.</P>

<P><B>Notes from October 2004 meeting:</B></P>

<P>The C99 Standard appears to be inconsistent in its
requirements.  For example, 6.2.6.1 paragraph 4 says:</P>

<BLOCKQUOTE>

The value may be copied into an object of type
<TT>unsigned&#160;char&#160;[</TT><I>n</I><TT>]</TT> (e.g., by
<TT>memcpy</TT>); the resulting set of bytes is called the
<I>object representation</I> of the value.

</BLOCKQUOTE>

<P>On the other hand, 6.2 paragraph 6 says,</P>

<BLOCKQUOTE>

If a value is copied into an object having no declared type using
<TT>memcpy</TT> or <TT>memmove</TT>, or is copied as an array of
character type, then the effective type of the modified object
for that access and for subsequent accesses that do not modify
the value is the effective type of the object from which the
value is copied, if it has one.

</BLOCKQUOTE>

<P>Mike Miller will investigate further.</P>

<P><B>Proposed resolution (February, 2010):</B></P>

<OL><LI><P>Change 3.8 [basic.life] paragraph 5 bullet 4 as
follows:</P></LI>

<BLOCKQUOTE>

<P>...The program has undefined behavior if:</P>

<UL><LI><P>...</P></LI>

<LI><P>the pointer is used as the operand of a
<TT>static_cast</TT> (5.2.9 [expr.static.cast]) (except when
the conversion is to <SPAN style="font-weight:bold;background-color:#A0FFA0"><I>cv</I></SPAN> <TT>void*</TT>, or to
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>cv</I></SPAN> <TT>void*</TT> and subsequently to
<SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>char*</TT>, or <TT>unsigned char*</TT></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a
pointer to a cv-qualified or cv-unqualified byte-character type
(3.9.1 [basic.fundamental])</SPAN>), or</P></LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change 3.8 [basic.life] paragraph 6 bullet 4 as
follows:</P></LI>

<BLOCKQUOTE>

<P>...The program has undefined behavior if:</P>

<UL><LI><P>...</P></LI>

<LI><P>the lvalue is used as the operand of a
<TT>static_cast</TT> (5.2.9 [expr.static.cast]) except when the
conversion is ultimately to <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>cv</I> <TT>char&amp;</TT> or
<I>cv</I> <TT>unsigned char&amp;</TT></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a reference to a
cv-qualified or cv-unqualified byte-character type (3.9.1 [basic.fundamental]) or an array thereof</SPAN>, or</P></LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change 3.9 [basic.types] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

For any object (other than a base-class subobject) of trivially
copyable type <TT>T</TT>, whether or not the object holds a valid
value of type <TT>T</TT>, the underlying bytes (1.7 [intro.memory]) making up the object can be copied into an array of
<SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>char</TT> or <TT>unsigned char</TT></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a
byte-character type (3.9.1 [basic.fundamental])</SPAN>.<SUP>39</SUP> If the content of
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">the</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">that</SPAN> array <SPAN style="text-decoration:line-through;background-color:#FFA0A0">of <TT>char</TT> or
<TT>unsigned char</TT></SPAN> is copied back into the object, the
object shall subsequently hold its original
value. [<I>Example:</I>...

</BLOCKQUOTE>

<LI><P>Change 3.9.1 [basic.fundamental] paragraph 1 as follows:</P></LI>

<BLOCKQUOTE>

...Characters can be explicitly declared <TT>unsigned</TT> or
<TT>signed</TT>.  Plain <TT>char</TT>, <TT>signed char</TT>, and
<TT>unsigned char</TT> are three distinct types<SPAN style="font-weight:bold;background-color:#A0FFA0">, called the
<I>byte-character types</I></SPAN>.  A <TT>char</TT>, a <TT>signed
char</TT>, and an <TT>unsigned char</TT> occupy the same amount
of storage and have the same alignment requirements (3.11 [basic.align]); that is, they have the same object
representation. For <SPAN style="font-weight:bold;background-color:#A0FFA0">byte-</SPAN>character types, all bits of
the object representation participate in the value
representation.  For <SPAN style="text-decoration:line-through;background-color:#FFA0A0">unsigned character types</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>unsigned char</TT></SPAN>, all possible bit patterns of
the value representation represent numbers...

</BLOCKQUOTE>

<LI><P>Change 3.10 [basic.lval] paragraph 15 final bullet
as follows:</P></LI>

<BLOCKQUOTE>

<P>If a program attempts to access the stored value of an object
through an lvalue of other than one of the following types the
behavior is undefined <SUP>52</SUP></P>

<UL>

<LI><P>...</P></LI>

<LI><P>a <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>char</TT> or <TT>unsigned char</TT></SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">byte-character</SPAN> type <SPAN style="font-weight:bold;background-color:#A0FFA0">(3.9.1 [basic.fundamental])</SPAN>.</P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change 3.11 [basic.align] paragraph 6 as follows:</P></LI>

<BLOCKQUOTE>

The alignment requirement of a complete type can be queried using
an <TT>alignof</TT> expression (5.3.6 [expr.alignof]).
Furthermore, the <SPAN style="font-weight:bold;background-color:#A0FFA0">byte-character</SPAN> types
<SPAN style="font-weight:bold;background-color:#A0FFA0">(3.9.1 [basic.fundamental])</SPAN> <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>char</TT>,
<TT>signed char</TT>, and <TT>unsigned char</TT></SPAN> shall have
the weakest alignment requirement.  [<I>Note:</I> this enables
the <SPAN style="font-weight:bold;background-color:#A0FFA0">byte-</SPAN>character types to be used as the underlying
type for an aligned memory area (7.6.2 [dcl.align]). &#8212;<I>end note</I>]

</BLOCKQUOTE>

<LI><P>Change 5.3.4 [expr.new] paragraph 10 as follows:</P></LI>

<BLOCKQUOTE>

...For arrays of <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><TT>char</TT> and <TT>unsigned
char</TT></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a byte-character type (3.9.1 [basic.fundamental])</SPAN>, the difference between the result of the
<I>new-expression</I> and the address returned by the allocation
function shall be an integral multiple of the strictest
fundamental alignment requirement (3.11 [basic.align]) of
any object type whose size is no greater than the size of the
array being created. [<I>Note:</I> Because allocation functions
are assumed to return pointers to storage that is appropriately
aligned for objects of any type with fundamental alignment, this
constraint on array allocation overhead permits the common idiom
of allocating <SPAN style="font-weight:bold;background-color:#A0FFA0">byte-</SPAN>character arrays into which objects
of other types will later be placed. &#8212;<I>end note</I>]

</BLOCKQUOTE>

</OL>

<P><B>Notes from the March, 2010 meeting:</B></P>

<P>The CWG was not convinced that there was a need to change the
existing specification at this time.  Some were concerned that there
might be implementation difficulties with giving <TT>signed char</TT>
the requisite semantics; implementations for which that is true can
currently make <TT>char</TT> equivalent to <TT>unsigned char</TT> and
avoid those problems, but the suggested change would undermine that
strategy.</P>

<BR><BR><HR><A NAME="1746"></A><H4>1746.
  
Are volatile scalar types trivially copyable?
</H4><B>Section: </B>3.9&#160; [basic.types]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Walter Brown
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-06<BR>




<P>According to 3.9 [basic.types] paragraph 9,</P>

<BLOCKQUOTE>

Arithmetic types (3.9.1 [basic.fundamental]), enumeration types, pointer
types, pointer to member types (3.9.2 [basic.compound]),
<TT>std::nullptr_t</TT>, and cv-qualified versions of these types
(3.9.3 [basic.type.qualifier]) are collectively called <I>scalar types</I>...
Scalar types, trivially copyable class types (Clause
9 [class]), arrays of such types, and non-volatile
const-qualified versions of these types (3.9.3 [basic.type.qualifier]) are
collectively called <I>trivially copyable types</I>.

</BLOCKQUOTE>

<P>This is confusing, because &#8220;scalar types&#8221; include
volatile-qualified types, but the intent of the definition of
&#8220;trivially copyable type&#8221; appears to be to exclude
volatile-qualified types.  Perhaps the second quoted sentence should
read something like,</P>

<BLOCKQUOTE>

A non-volatile type <TT>T</TT> or an array of such <TT>T</TT> is called a
trivially copyable type if <TT>T</TT> is either a scalar type or a
trivially copyable class type.

</BLOCKQUOTE>

<P>(Note that the following sentence, defining &#8220;trivial type,&#8221;
has a similar formal issue, although it has no actual significance because
all cv-qualifiers are permitted.)</P>

<BR><BR><HR><A NAME="146"></A><H4>146.
  
Floating-point zero
</H4><B>Section: </B>3.9.1&#160; [basic.fundamental]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Andy Sawyer
 &#160;&#160;&#160;

 <B>Date: </B>23 Jul 1999<BR>





<P>3.9.1 [basic.fundamental]
 does not impose
a requirement on the floating point types that there be an exact
representation of the value zero.  This omission is significant in
4.12 [conv.bool]
 paragraph 1, in which any
non-zero value converts to the <TT>bool</TT> value <TT>true</TT>.</P>

<P>Suggested resolution: require that all floating point types have an
exact representation of the value zero.</P>
<BR><BR><HR><A NAME="251"></A><H4>251.
  
How many signed integer types are there?
</H4><B>Section: </B>3.9.1&#160; [basic.fundamental]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Beman Dawes
 &#160;&#160;&#160;

 <B>Date: </B>18 Oct 2000<BR>




<P>3.9.1 [basic.fundamental] paragraph 2 says that</P>

<BLOCKQUOTE>

There are four <I>signed integer types</I>: "<TT>signed char</TT>",
"<TT>short int</TT>", "<TT>int</TT>", and "<TT>long int</TT>."

</BLOCKQUOTE>

<P>This would indicate that <TT>const int</TT> is not a signed
integer type.</P>

<BR><BR><HR><A NAME="689"></A><H4>689.
  
Maximum values of signed and unsigned integers
</H4><B>Section: </B>3.9.1&#160; [basic.fundamental]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>James Kanze
 &#160;&#160;&#160;

 <B>Date: </B>30 March, 2008<BR>




<P>The relationship between the values representable by corresponding
signed and unsigned integer types is not completely described, but
3.9 [basic.types] paragraph 4 says,</P>

<BLOCKQUOTE>

The <I>value representation</I> of an object is the set of bits that
hold the value of type <TT>T</TT>.

</BLOCKQUOTE>

<P>and 3.9.1 [basic.fundamental] paragraph 3 says,</P>

<BLOCKQUOTE>

The range of nonnegative values of a signed integer type is a
subrange of the corresponding unsigned integer type, and the
value representation of each corresponding signed/unsigned type
shall be the same.

</BLOCKQUOTE>

<P>I.e., the maximum value of each unsigned type must be larger
than the maximum value of the corresponding signed type.</P>

<P>C90 doesn't have this restriction, and C99 explicitly says
(6.2.6.2, paragraph 2),</P>

<BLOCKQUOTE>

For signed integer types, the bits of the object representation
shall be divided into three groups: value bits, padding bits, and
the sign bit. There need not be any padding bits; there shall be
exactly one sign bit. Each bit that is a value bit shall have the
same value as the same bit in the object representation of the
corresponding unsigned type (if there are <I>M</I> value bits in the
signed type and N in the unsigned type, then <I>M</I> &lt;= <I>N</I>).

</BLOCKQUOTE>

<P>Unlike C++, the sign bit is not part of the value, and on an
architecture that does not have native support of unsigned types,
an implementation can emulate unsigned integers by simply
ignoring what would be the sign bit in the signed type and be
conforming.</P>

<P>The question is whether we intend to make a conforming
implementation on such an architecture impossible. More
generally, what range of architectures do we intend to
support?  And to what degree do we want to follow C99 in
its evolution since C89?</P>

<P>(See paper J16/08-0141 = WG21 N2631.)</P>

<BR><BR><HR><A NAME="1076"></A><H4>1076.
  
Value categories and lvalue temporaries
</H4><B>Section: </B>3.10&#160; [basic.lval]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2010-06-10<BR>


<P>The taxonomy of value categories in 3.10 [basic.lval]
classifies temporaries as prvalues.  However, some temporaries are
explicitly referred to as lvalues (cf 15.1 [except.throw]
paragraph 3).</P>

<BR><BR><HR><A NAME="330"></A><H4>330.
  
Qualification conversions and pointers to arrays of pointers
</H4><B>Section: </B>4.4&#160; [conv.qual]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Roger Orr
 &#160;&#160;&#160;

 <B>Date: </B>2 Jan 2002<BR>


<P>Section 4.4 [conv.qual]
covers the case of multi-level pointers, but does not appear to cover the
case of pointers to arrays of pointers.
The effect is that arrays are treated differently from simple scalar
values.</P>

<P>Consider for example the following code:
(from the thread "Pointer to array conversion question" begun in
comp.lang.c++.moderated)
<PRE>
  int main()
  {
     double *array2D[2][3];
  
     double       *       (*array2DPtr1)[3] = array2D;     // Legal
     double       * const (*array2DPtr2)[3] = array2DPtr1; // Legal
     double const * const (*array2DPtr3)[3] = array2DPtr2; // Illegal
  }
</PRE>
and compare this code with:-
<PRE>
  int main()
  {
     double *array[2];
  
     double       *       *ppd1 = array; // legal
     double       * const *ppd2 = ppd1;  // legal
     double const * const *ppd3 = ppd2;  // certainly legal (4.4/4)
  }
</PRE>
</P>

<P>The problem appears to be that the pointed to types in example 1 are
unrelated since nothing in the
relevant section of the standard covers it - 4.4 [conv.qual]
does not mention conversions of the form
"cv array of N pointer to T"
into
"cv array of N pointer to cv T"</P>

<P>It appears that reinterpret_cast is the only way to perform the
conversion.</P>

<P><B>Suggested resolution:</B></P>

<P>Artem Livshits proposed a resolution :-</P>

<P>"I suppose if the definition of "similar" pointer types in
4.4 [conv.qual] paragraph 4 was
rewritten like this:
<BLOCKQUOTE>
<P>T1 is cv1,0 P0 cv1,1 P1 ... cv1,n-1 Pn-1 cv1,n T</P>
<P>and</P>
<P>T2 is cv1,0 P0 cv1,1 P1 ... cv1,n-1 Pn-1 cv1,n T</P>

<P>where Pi is either a "pointer to" or a "pointer to an array of Ni"; besides
P0 may be also a "reference to" or a "reference to an array of N0" (in the
case of P0 of T2 being a reference, P0 of T1 may be nothing).</P>
</BLOCKQUOTE>
it would address the problem.</P>

<P>In fact I guess Pi in this notation may be also a "pointer to member", so
4.4 [conv.qual]/{4,5,6,7} would be nicely wrapped in one
paragraph."</P>

<BR><BR><HR><A NAME="238"></A><H4>238.
  
Precision and accuracy constraints on floating point
</H4><B>Section: </B>5&#160; [expr]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Christophe de Dinechin
 &#160;&#160;&#160;

 <B>Date: </B>31 Jul 2000<BR>




<P>It is not clear what constraints are placed on a floating point
implementation by the wording of the Standard.  For instance, is
an implementation permitted to generate a "fused multiply-add"
instruction if the result would be different from what would
be obtained by performing the operations separately?  To what
extent does the "as-if" rule allow the kinds of optimizations
(e.g., loop unrolling) performed by FORTRAN compilers?</P>

<BR><BR><HR><A NAME="1642"></A><H4>1642.
  
Missing requirements for prvalue operands
</H4><B>Section: </B>5&#160; [expr]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Joseph Mansfield
 &#160;&#160;&#160;

 <B>Date: </B>2013-03-15<BR>


<P>Although the note in 3.10 [basic.lval] paragraph 1
states that</P>

<BLOCKQUOTE>

The discussion of each built-in operator in Clause
5 [expr] indicates the category of the value
it yields and the value categories of the operands it
expects

</BLOCKQUOTE>

<P>in fact, many of the operators that take prvalue operands
do not make that requirement explicit.  Possible approaches
to address this failure could be a blanket statement that an
operand whose value category is not stated is assumed to be
a prvalue; adding prvalue requirements to each operand
description for which it is missing; or changing the
description of the usual arithmetic conversions to state
that they imply the lvalue-to-rvalue conversion, which would
cover the majority of the omissions.</P>

<P>(See also <A HREF="
     cwg_active.html#1685">issue 1685</A>, which deals with
an inaccurately-specified value category.)</P>

<BR><BR><HR><A NAME="1632"></A><H4>1632.
  
Lambda capture in member initializers
</H4><B>Section: </B>5.1.2&#160; [expr.prim.lambda]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Vinny Romano
 &#160;&#160;&#160;

 <B>Date: </B>2013-03-04<BR>




<P>According to 5.1.2 [expr.prim.lambda] paragraph 9,</P>

<BLOCKQUOTE>

A <I>lambda-expression</I> whose smallest enclosing scope is a block scope
(3.3.3 [basic.scope.block]) is a local lambda expression; any
other <I>lambda-expression</I> shall not have a <I>capture-list</I> in
its <I>lambda-introducer</I>. The reaching scope of a local lambda
expression is the set of enclosing scopes up to and including the innermost
enclosing function and its parameters.

</BLOCKQUOTE>

<P>Consequently, lambdas appearing in <I>mem-initializer</I>s and
<I>brace-or-equal-initializer</I>s cannot have a <I>capture-list</I>.
However, these expressions are evaluated in the context of the
constructor and are permitted to access <TT>this</TT> and
non-static data members.</P>

<P>Should the definition of a local lambda be modified to permit
capturing lambdas within these contexts?</P>

<P><B>Notes from the April, 2013 meeting:</B></P>

<P>CWG agreed with the intent of this issue.</P>

<BR><BR><HR><A NAME="1743"></A><H4>1743.
  
<I>init-capture</I>s in nested lambdas
</H4><B>Section: </B>5.1.2&#160; [expr.prim.lambda]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Faisal Vali
 &#160;&#160;&#160;

 <B>Date: </B>2013-08-30<BR>




<P>According to 5.2.1 [expr.sub] paragraph 11,</P>

<BLOCKQUOTE>

No entity is captured by an <I>init-capture</I>.

</BLOCKQUOTE>

<P>It should be made clearer that a variable, odr-used by
an <I>init-capture</I> in a nested lambda, is still captured by the
containing lambda as a result of the <I>init-capture</I>.</P>

<BR><BR><HR><A NAME="1780"></A><H4>1780.
  
Explicit instantiation/specialization of generic lambda <TT>operator()</TT>
</H4><B>Section: </B>5.1.2&#160; [expr.prim.lambda]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-26<BR>


<P>Similarly to <A HREF="
     cwg_active.html#1738">issue 1738</A>, it is not clear
whether it is permitted to explicitly instantiate or specialize the
call operator of a polymorphic lambda (via <TT>decltype</TT>).</P>

<BR><BR><HR><A NAME="943"></A><H4>943.
  
Is <TT>T()</TT> a temporary?
</H4><B>Section: </B>5.2.3&#160; [expr.type.conv]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Miller
 &#160;&#160;&#160;

 <B>Date: </B>14 July, 2009<BR>


<P>According to 5.2.3 [expr.type.conv] paragraphs 1 and 3 (stated
directly or by reference to another section of the Standard), all the
following expressions create temporaries:</P>

<PRE>
    T(1)
    T(1, 2)
    T{1}
    T{}
</PRE>

<P>However, paragraph 2 says,</P>

<BLOCKQUOTE>

The expression <TT>T()</TT>, where <TT>T</TT> is a
<I>simple-type-specifier</I> or <I>typename-specifier</I> for a
non-array complete effective object type or the (possibly
cv-qualified) <TT>void</TT> type, creates an rvalue of the specified
type, which is value-initialized (8.5 [dcl.init]; no
initialization is done for the <TT>void()</TT> case).

</BLOCKQUOTE>

<P>This does <I>not</I> say that the result is a temporary, which
means that the lifetime of the result is not specified by
12.2 [class.temporary].  Presumably this is just an oversight.</P>

<P><B>Notes from the October, 2009 meeting:</B></P>

<P>The specification in 5.2.3 [expr.type.conv] is in error, not
because it fails to state that <TT>T()</TT> is a temporary but because
it requires a temporary for the other cases with fewer than two operands.
The case where <TT>T</TT> is a class type is covered by
12.2 [class.temporary] paragraph 1 (&#8220;a conversion that creates
an rvalue&#8221;), and a temporary should <I>not</I> be created when
<TT>T</TT> is not a class type.</P>

<BR><BR><HR><A NAME="742"></A><H4>742.
  
Postfix increment/decrement with long bit-field operands
</H4><B>Section: </B>5.2.6&#160; [expr.post.incr]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>11 November, 2008<BR>


<P>Given the following declarations:</P>

<PRE>
    struct S {
        signed long long sll: 3;
    };
    S s = { -1 };
</PRE>

<P>the expressions <TT>s.sll-- &lt; 0u</TT> and <TT>s.sll &lt; 0u</TT>
have different results.  The reason for this is that <TT>s.sll--</TT>
is an rvalue of type <TT>signed long long</TT> (5.2.6 [expr.post.incr]), which means that the usual arithmetic conversions
(5 [expr] paragraph 10) convert <TT>0u</TT> to
<TT>signed long long</TT> and the result is <TT>true</TT>.
<TT>s.sll</TT>, on the other hand, is a bit-field lvalue, which is
promoted (4.5 [conv.prom] paragraph 3) to <TT>int</TT>; both
operands of <TT>&lt;</TT> have the same rank, so <TT>s.sll</TT> is
converted to <TT>unsigned int</TT> to match the type of <TT>0u</TT>
and the result is <TT>false</TT>.  This disparity seems
undesirable.</P>

<BR><BR><HR><A NAME="282"></A><H4>282.
  
Namespace for <TT>extended_type_info</TT>
</H4><B>Section: </B>5.2.8&#160; [expr.typeid]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jens Maurer
 &#160;&#160;&#160;

 <B>Date: </B>01 May 2001<BR>


<P>The original proposed resolution for <A HREF="
     cwg_defects.html#160">issue 160</A>
included changing <TT>extended_type_info</TT>
(5.2.8 [expr.typeid] paragraph 1, footnote 61) to
<TT>std::extended_type_info</TT>.  There was no consensus on whether
this name ought to be part of namespace <TT>std</TT> or in a
vendor-specific namespace, so the question was moved into a
separate issue.</P>

<BR><BR><HR><A NAME="528"></A><H4>528.
  
Why are incomplete class types not allowed with <TT>typeid</TT>?
</H4><B>Section: </B>5.2.8&#160; [expr.typeid]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Dave Abrahams
 &#160;&#160;&#160;

 <B>Date: </B>18 May 2005<BR>




<P>5.2.8 [expr.typeid] paragraph 4 says,</P>

<BLOCKQUOTE>

When <TT>typeid</TT> is applied to a <I>type-id</I>, the result refers
to a <TT>std::type_info</TT> object representing the type of
the <I>type-id</I>.  If the type of the <I>type-id</I> is a reference
type, the result of the <TT>typeid</TT> expression refers to
a <TT>std::type_info</TT> object representing the referenced type. If
the type of the <I>type-id</I> is a class type or a reference to a
class type, the class shall be completely-defined.

</BLOCKQUOTE>

<P>I'm wondering whether this is not overly restrictive.  I can't
think of a reason to require that <TT>T</TT> be completely-defined
in <TT>typeid(T)</TT> when <TT>T</TT> is a class type.  In fact,
several popular compilers enforce that restriction
for <TT>typeid(T)</TT>, but not for <TT>typeid(T&amp;)</TT>.  Can
anyone explain this?
</P>

<P><U>Nathan Sidwell</U>: I think this restriction is so that whenever
the compiler has to emit a typeid object of a class type, it knows
what the base classes are, and can therefore emit an array of
pointers-to-base-class typeids.  Such a tree is necessary to implement
<TT>dynamic_cast</TT> and exception catching (in a commonly
implemented and obvious manner).  If the class could be incomplete,
the compiler might have to emit a typeid for incomplete <TT>Foo</TT>
in one object file and a typeid for complete <TT>Foo</TT> in another
object file.  The compilation system will then have to make sure that
(a) those compare equal and (b) the complete <TT>Foo</TT> gets
priority, if that is applicable.
</P>

<P>Unfortunately, there is a problem with exceptions that means there
still can be a need to emit typeids for incomplete class.  Namely one
can throw a pointer-to-pointer-to-incomplete.  To implement the
matching of pointer-to-derived being caught by pointer-to-base, it is
necessary for the typeid of a pointer type to contain a pointer to the
typeid of the pointed-to type.  In order to do the qualification
matching on a multi-level pointer type, one has a chain of pointer
typeids that can terminate in the typeid of an incomplete type.  You
cannot simply NULL-terminate the chain, because one must distinguish
between different incomplete types.</P>

<P><U>Dave Abrahams</U>: So if implementations are still required to
be able to do it, for all practical purposes, why aren't we letting
the user have the benefits?</P>

<P><B>Notes from the April, 2006 meeting:</B></P>

<P>There was some concern expressed that this might be difficult under
the IA64 ABI.  It was also observed that while it is necessary to
handle exceptions involving incomplete types, there is no requirement
that the RTTI data structures be used for exception handling.</P>

<BR><BR><HR><A NAME="944"></A><H4>944.
  
<TT>reinterpret_cast</TT> for all types with the same size and alignment
</H4><B>Section: </B>5.2.10&#160; [expr.reinterpret.cast]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Miller
 &#160;&#160;&#160;

 <B>Date: </B>15 July, 2009<BR>


<P>During the discussion of <A HREF="
     cwg_defects.html#799">issue 799</A>, which
specified the result of using <TT>reinterpret_cast</TT> to convert an
operand to its own type, it was observed that it is probably reasonable
to allow <TT>reinterpret_cast</TT> between any two types that have the
same size and alignment.</P>

<BR><BR><HR><A NAME="1230"></A><H4>1230.
  
Confusing description of ambiguity of destructor name
</H4><B>Section: </B>5.3.1&#160; [expr.unary.op]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2010-12-13<BR>




<P>According to 5.3.1 [expr.unary.op] paragraph 10,</P>

<BLOCKQUOTE>

There is an ambiguity in the <I>unary-expression</I> <TT>~X()</TT>,
where <TT>X</TT> is a <I>class-name</I> or <I>decltype-specifier</I>.
The ambiguity is resolved in favor of treating <TT>~</TT> as a
unary complement rather than treating <TT>~X</TT> as referring
to a destructor.

</BLOCKQUOTE>

<P>It is not clear whether this is intended to apply to an
expression like <TT>(~S)()</TT>.  In large measure, that depends on
whether a <I>class-name</I> is an <I>id-expression</I> or not.  If it
is, the ambiguity described in 5.3.1 [expr.unary.op] paragraph
10 does apply; if not, the expression is an unambiguous reference to
the destructor for class <TT>S</TT>.  There are several places in the
Standard that indicate that the name of a type is an
<I>id-expression</I>, but that might be more confusing than helpful.</P>

<BR><BR><HR><A NAME="267"></A><H4>267.
  
Alignment requirement for <I>new-expression</I>s
</H4><B>Section: </B>5.3.4&#160; [expr.new]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>James Kuyper
 &#160;&#160;&#160;

 <B>Date: </B>4 Dec 2000<BR>


<P>Requirements for the alignment of pointers returned by
<I>new-expression</I>s are given in 5.3.4 [expr.new]
paragraph 10:</P>

<BLOCKQUOTE>

For arrays of <TT>char</TT> and <TT>unsigned char</TT>, the difference
between the result of the <I>new-expression</I> and the address
returned by the allocation function shall be an integral multiple of
the most stringent alignment requirement (3.9 [basic.types])
of any object type whose size is no greater than the size of the array
being created.

</BLOCKQUOTE>

<P>The intent of this wording is that the pointer returned by the
<I>new-expression</I> will be suitably aligned for any data type
that might be placed into the allocated storage (since the
allocation function is constrained to return a pointer to
maximally-aligned storage).  However, there is an implicit
assumption that each alignment requirement is an integral multiple
of all smaller alignment requirements.  While this is probably a
valid assumption for all real architectures, there's no reason
that the Standard should require it.</P>

<P>For example, assume that <TT>int</TT> has an alignment requirement
of 3 bytes and <TT>double</TT> has an alignment requirement of 4
bytes.  The current wording only requires that a buffer that is big
enough for an <TT>int</TT> or a <TT>double</TT> be aligned on a 4-byte
boundary (the more stringent requirement), but that would allow the
buffer to be allocated on an 8-byte boundary &#8212; which might
<I>not</I> be an acceptable location for an <TT>int</TT>.</P>

<P><U>Suggested resolution</U>: Change "of any object type" to
"of every object type."</P>

<P>A similar assumption can be found in
5.2.10 [expr.reinterpret.cast] paragraph 7:</P>

<BLOCKQUOTE>

...converting an rvalue of type "pointer to <TT>T1</TT>" to the type
"pointer to <TT>T2</TT>" (where ... the alignment requirements of
<TT>T2</TT> are no stricter than those of <TT>T1</TT>) and back to its
original type yields the original pointer value...

</BLOCKQUOTE>

<P><U>Suggested resolution</U>: Change the wording to</P>

<BLOCKQUOTE>

...converting an rvalue of type "pointer to <TT>T1</TT>" to the type
"pointer to <TT>T2</TT>" (where ...  the alignment requirements of
<SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>T1</TT> are an integer multiple of those of <TT>T2</TT></SPAN>)
and back to its original type yields the original pointer value...

</BLOCKQUOTE>

<P>The same change would also be needed in paragraph 9.</P>

<BR><BR><HR><A NAME="473"></A><H4>473.
  
Block-scope declarations of allocator functions
</H4><B>Section: </B>5.3.4&#160; [expr.new]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>12 Jul 2004<BR>


<P>Looking up <TT>operator new</TT> in a <I>new-expression</I>
uses a different mechanism from ordinary lookup.  According to
5.3.4 [expr.new] paragraph 9,</P>

<BLOCKQUOTE>
If the <I>new-expression</I> begins with a unary <TT>::</TT>
operator, the allocation function's name is looked up in the
global scope. Otherwise, if the allocated type is a class type
<TT>T</TT> or array thereof, the allocation function's name is
looked up in the scope of <TT>T</TT>. If this lookup fails to
find the name, or if the allocated type is not a class type, the
allocation function's name is looked up in the global scope.
</BLOCKQUOTE>

<P>Note in particular that the scope in which the
<I>new-expression</I> occurs is not considered.  For example,</P>

<PRE>
    void f() {
        void* operator new(std::size_t, void*);
        int* i = new int;    // okay?
    }
</PRE>

<P>In this example, the implicit reference to <TT>operator
new(std::size_t)</TT> finds the global declaration, even though
the block-scope declaration of <tt>operator new</tt> with a
different signature would hide it from an ordinary reference.</P>

<P>This seems strange; either the block-scope declaration should
be ill-formed or it should be found by the lookup.</P>

<P><B>Notes from October 2004 meeting:</B></P>

<P>The CWG agreed that the block-scope declaration should not be
found by the lookup in a <I>new-expression</I>.  It would,
however, be found by ordinary lookup if the allocation function
were invoked explicitly.</P>

<BR><BR><HR><A NAME="1628"></A><H4>1628.
  
Deallocation function templates
</H4><B>Section: </B>5.3.4&#160; [expr.new]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-02-22<BR>




<P>According to 5.3.4 [expr.new] paragraphs 18-20, an
exception thrown during the initialization of an object allocated
by a <I>new-expression</I> will cause a deallocation
function to be called for the object's storage if a matching
deallocation function can be found.  The rules deal only with
functions, however; nothing is said regarding a mechanism by which
a deallocation function template might be instantiated to free the
storage, although 3.7.4.2 [basic.stc.dynamic.deallocation] paragraph 2 indicates
that a deallocation function can be an instance of a function
template.</P>

<P>One possibility for this processing might be to perform template
argument deduction on any deallocation function templates; if there
is a specialization that matches the allocation function, by the
criteria listed in paragraph 20, that function template would be
instantiated and used, although a matching non-template function would
take precedence as is the usual outcome of overloading between
function template specializations and non-template functions.</P>

<P>Another possibility might be to match non-template deallocation
functions with non-template allocation functions and template
deallocation functions with template allocation functions.</P>

<P>There is a slightly related wording problem in
5.3.4 [expr.new] paragraph 21:</P>

<BLOCKQUOTE>

If a placement deallocation function is called, it is passed the same
additional arguments as were passed to the placement allocation function,
that is, the same arguments as those specified with
the <I>new-placement</I> syntax.

</BLOCKQUOTE>

<P>This wording ignores the possibility of default arguments in the
allocation function, in which case the arguments passed to the
deallocation function might be a superset of those specified in the
<I>new-placement</I>.</P>

<P>(See also <A HREF="
     cwg_active.html#1682">issue 1682</A>.)</P>

<BR><BR><HR><A NAME="1748"></A><H4>1748.
  
Placement new with a null pointer
</H4><B>Section: </B>5.3.4&#160; [expr.new]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Marc Glisse
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-11<BR>




<P>According to 5.3.4 [expr.new] paragraph 15,</P>

<BLOCKQUOTE>

[<I>Note:</I> unless an allocation function is declared with a
non-throwing <I>exception-specification</I> (15.4 [except.spec]), it
indicates failure to allocate storage by throwing a <TT>std::bad_alloc</TT>
exception (Clause 15 [except], 18.6.2.1 [bad.alloc]);
it returns a non-null pointer otherwise. If the allocation function is
declared with a non-throwing <I>exception-specification</I>, it returns
null to indicate failure to allocate storage and a non-null pointer
otherwise. &#8212;<I>end note</I>] If the allocation function returns null,
initialization shall not be done, the deallocation function shall not be
called, and the value of the <I>new-expression</I> shall be null.

</BLOCKQUOTE>

<P>This wording applies even to the non-replaceable placement forms defined
in 18.6.1.3 [new.delete.placement] that simply return the supplied pointer as
the result of the allocation function.  Compilers are thus required to
check for a null pointer and avoid the initialization if one is used.  This
test is unnecessary overhead; it should be the user's responsibility to
ensure that a null pointer is not used in these forms of placement new,
just as for other cases when a pointer is dereferenced.</P>

<BR><BR><HR><A NAME="196"></A><H4>196.
  
Arguments to deallocation functions </H4><B>Section: </B>5.3.5&#160; [expr.delete]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Matt Austern
 &#160;&#160;&#160;

 <B>Date: </B>20 Jan 2000<BR>





<P>5.3.4 [expr.new]
 paragraph 10 says that
the result of an array allocation function and the value of the array
<I>new-expression</I> from which it was invoked may be different,
allowing for space preceding the array to be used for implementation
purposes such as saving the number of elements in the array.  However,
there is no corresponding description of the relationship between the
operand of an array <I>delete-expression</I> and the argument passed
to its deallocation function.</P>

<P>3.7.4.2 [basic.stc.dynamic.deallocation]

paragraph 3 does state that</P>

<BLOCKQUOTE>
the value supplied to <TT>operator delete[](void*)</TT> in the
standard library shall be one of the values returned by a previous
invocation of either <TT>operator new[](std::size_t)</TT> or
<TT>operator new[](std::size_t, const std::nothrow_t&amp;)</TT> in the
standard library.
</BLOCKQUOTE>

<P>This statement might be read as requiring an implementation, when
processing an array <I>delete-expression</I> and calling the
deallocation function, to perform the inverse of the calculation
applied to the result of the allocation function to produce the value
of the <I>new-expression</I>.
(5.3.5 [expr.delete]
 paragraph 2 requires
that the operand of an array <I>delete-expression</I> "be the pointer
value which resulted from a previous array <I>new-expression</I>.")
However, it is not completely clear whether the "shall" expresses an
implementation requirement or a program requirement (or both).
Furthermore, there is no direct statement about user-defined
deallocation functions.</P>

<P><B>Suggested resolution:</B> A note should be added to
5.3.5 [expr.delete]
 to clarify that any
offset added in an array <I>new-expression</I> must be subtracted in
the array <I>delete-expression</I>.</P>
<BR><BR><HR><A NAME="1788"></A><H4>1788.
  
Sized deallocation of array of non-class type
</H4><B>Section: </B>5.3.5&#160; [expr.delete]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-29<BR>


<P>The changes from N3778 require use of a sized deallocator for a case
like</P>

<PRE>
  char *p = new char[32];
  void f() { delete [] p; }
</PRE>

<P>That is unimplementable under current ABIs, which do not store the
array size for such allocations.  It should instead be unspecified or
implementation-defined whether the sized form of <TT>operator[]</TT> is
used for a pointer to a type other than a class with a non-trivial
destructor or array thereof.</P>

<BR><BR><HR><A NAME="242"></A><H4>242.
  
Interpretation of old-style casts
</H4><B>Section: </B>5.4&#160; [expr.cast]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>30 Aug 2000<BR>




<P>The meaning of an old-style cast is described in terms of
<TT>const_cast</TT>, <TT>static_cast</TT>, and
<TT>reinterpret_cast</TT> in 5.4 [expr.cast] paragraph 5.
Ignoring <TT>const_cast</TT> for the moment, it basically says that if
the conversion performed by a given old-style cast is one of those
performed by <TT>static_cast</TT>, the conversion is interpreted as if
it were a <TT>static_cast</TT>; otherwise, it's interpreted as if it
were a <TT>reinterpret_cast</TT>, if possible.  The following example
is given in illustration:</P>

<PRE>
    struct A {};
    struct I1 : A {};
    struct I2 : A {};
    struct D : I1, I2 {};
    A *foo( D *p ) {
	return (A*)( p ); // ill-formed static_cast interpretation
    }
</PRE>

<P>The obvious intent here is that a derived-to-base pointer
conversion is one of the conversions that can be performed using
<TT>static_cast</TT>, so <TT>(A*)(p)</TT> is equivalent to
<TT>static_cast&lt;A*&gt;(p)</TT>, which is ill-formed because of the
ambiguity.</P>

<P>Unfortunately, the description of <TT>static_cast</TT> in
5.2.9 [expr.static.cast] does NOT support this interpretation.
The problem is in the way 5.2.9 [expr.static.cast] lists the
kinds of casts that can be performed using <TT>static_cast</TT>.
Rather than saying something like "All standard conversions can be
performed using <TT>static_cast</TT>," it says</P>

<BLOCKQUOTE>
An expression e can be explicitly converted to a type <TT>T</TT> using
a <TT>static_cast</TT> of the form <TT>static_cast&lt;T&gt;(e)</TT> if
the declaration "<TT>T t(e);</TT>" is well-formed, for some invented
temporary variable <TT>t</TT>.
</BLOCKQUOTE>

<P>Given the declarations above, the hypothetical declaration</P>

<PRE>
    A* t(p);
</PRE>

<P>is NOT well-formed, because of the ambiguity.  Therefore the old-style
cast <TT>(A*)(p)</TT> is NOT one of the conversions that can be performed
using <TT>static_cast</TT>, and <TT>(A*)(p)</TT> is equivalent to
<TT>reinterpret_cast&lt;A*&gt;(p)</TT>, which is well-formed under
5.2.10 [expr.reinterpret.cast] paragraph 7.</P>

<P>Other situations besides ambiguity which might raise similar
questions include access violations, casting from virtual base
to derived, and casting pointers-to-members when virtual
inheritance is involved.</P>

<BR><BR><HR><A NAME="1256"></A><H4>1256.
  
Unevaluated operands are not necessarily constant expressions
</H4><B>Section: </B>5.19&#160; [expr.const]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-08<BR>




<P>The current definition of constant expressions appears to make
unevaluated operands constant expressions; for example,
<TT>new char[10]</TT> would seem to be a constant expression if it
appears as the operand of <TT>sizeof</TT>.  This seems wrong.</P>

<BR><BR><HR><A NAME="1757"></A><H4>1757.
  
Const integral subobjects
</H4><B>Section: </B>5.19&#160; [expr.const]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-20<BR>


<P>The requirements for a constant expression in 5.19 [expr.const]
permit an lvalue-to-rvalue conversion on</P>

<BLOCKQUOTE>

 a non-volatile glvalue of integral or enumeration type that refers to a
 non-volatile const object with a preceding initialization, initialized
 with a constant expression

</BLOCKQUOTE>

<P>This does not exclude subobjects of objects that are not compile-time
constants, for example:</P>

<PRE>
  int f();
  struct S {
    S() : a(f()), b(5) {}
    int a, b;
  };
  const S s;
  constexpr int k = s.b;
</PRE>

<P>This rule is intended to provide backward compatibility with
pre-<TT>constexpr</TT> C++, but it should be restricted to complete
objects.  Care should be taken in resolving this issue not to break
the handling of string literals, since use of their elements in
constant expressions depends on the current form of this rule.</P>

<BR><BR><HR><A NAME="157"></A><H4>157.
  
Omitted typedef declarator
</H4><B>Section: </B>7&#160; [dcl.dcl]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>19 Aug 1999<BR>





<P>7 [dcl.dcl]
 paragraph 3 reads,</P>

<BLOCKQUOTE>
In a <I>simple-declaration</I>, the optional
<I>init-declarator-list</I> can be omitted only when... the
<I>decl-specifier-seq</I> contains either a <I>class-specifier</I>,
an <I>elaborated-type-specifier</I> with a <I>class-key</I>
(9.1 [class.name]
), or an
<I>enum-specifier</I>.  In these cases and whenever a
<I>class-specifier</I> or <I>enum-specifier</I> is present in the
<I>decl-specifier-seq</I>, the identifiers in those specifiers are
among the names being declared by the declaration...  In such cases,
and except for the declaration of an unnamed bit-field
(9.6 [class.bit]
), the
<I>decl-specifier-seq</I> shall introduce one or more names into the
program, or shall redeclare a name introduced by a previous
declaration.  [<I>Example:</I>

<PRE>
    enum { };           // <I>ill-formed</I>
    typedef class { };  // <I>ill-formed</I>
</PRE>

<I>&#8212;end example</I>]
</BLOCKQUOTE>

In the absence of any explicit restrictions in
7.1.3 [dcl.typedef]
, this paragraph appears
to allow declarations like the following:

<PRE>
    typedef struct S { };    // no declarator
    typedef enum { e1 };     // no declarator
</PRE>

In fact, the final example in
7 [dcl.dcl]
 paragraph 3 would seem to
indicate that this is intentional: since it is illustrating the
requirement that the <I>decl-specifier-seq</I> must introduce a name
in declarations in which the <I>init-declarator-list</I> is omitted,
presumably the addition of a class name would have made the example
well-formed.

<P>On the other hand, there is no good reason to allow such
declarations; the only reasonable scenario in which they might occur
is a mistake on the programmer's part, and it would be a service to
the programmer to require that such errors be diagnosed.</P>
<BR><BR><HR><A NAME="498"></A><H4>498.
  
Storage class specifiers in definitions of class members
</H4><B>Section: </B>7.1.1&#160; [dcl.stc]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Matt Austern
 &#160;&#160;&#160;

 <B>Date: </B>13 Jan 2005<BR>




<P>Suppose we've got this class definition:</P>

<PRE>
    struct X {
       void f();
       static int n;
    };
</PRE>

<P>I think I can deduce from the existing standard that the following 
member definitions are ill-formed:</P>

<PRE>
    static void X::f() { }
    static int X::n;
</PRE>

<P>To come to that conclusion, however, I have to put together several
things in different parts of the standard.  I would have expected to
find an explicit statement of this somewhere; in particular, I would
have expected to find it in 7.1.1 [dcl.stc].  I don't
see it there, or anywhere.</P>

<P><U>Gabriel Dos Reis</U>: Or in 3.5 [basic.link] which is
about linkage.  I would have expected that paragraph to say that that
members of class types have external linkage when the enclosing class
has an external linkage.  Otherwise 3.5 [basic.link]
paragraph 8:
</P>

<BLOCKQUOTE>

Names not covered by these rules have no linkage.

</BLOCKQUOTE>

<P>might imply that such members do not have linkage.</P>

<P><B>Notes from the April, 2005 meeting:</B></P>

<P>The question about the linkage of class members is already
covered by 3.5 [basic.link] paragraph 5.</P>

<BR><BR><HR><A NAME="1793"></A><H4>1793.
  
<TT>thread_local</TT> in explicit specializations
</H4><B>Section: </B>7.1.1&#160; [dcl.stc]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Herrick
 &#160;&#160;&#160;

 <B>Date: </B>2013-10-02<BR>


<P>According to 7.1.1 [dcl.stc] paragraph 1,</P>

<BLOCKQUOTE>

...If <TT>thread_local</TT> appears in any declaration of a variable it
shall be present in all declarations of that
entity... A <I>storage-class-specifier</I> shall not be specified in an
explicit specialization (14.7.3 [temp.expl.spec]) or an explicit
instantiation (14.7.2 [temp.explicit]) directive.

</BLOCKQUOTE>

<P>These two requirements appear to be in conflict when an explicit
instantiation or explicit specialization names a <TT>thread_local</TT>
variable.  For example,</P>

<PRE>
  template &lt;class T&gt; struct S {
    thread_local static int tlm;
  };
  template &lt;&gt; int S&lt;int&gt;::tlm = 0;
  template &lt;&gt; thread_local int S&lt;float&gt;::tlm = 0; 
</PRE>

<P>which of the two explicit specializations is correct?</P>

<BR><BR><HR><A NAME="1745"></A><H4>1745.
  
<TT>thread_local constexpr</TT> variable
</H4><B>Section: </B>7.1.5&#160; [dcl.constexpr]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-05<BR>


<P>Neither 7.1.5 [dcl.constexpr] nor 7.1.1 [dcl.stc]
forbids combining the <TT>thread_local</TT> and <TT>constexpr</TT>
specifiers in the declaration of a variable.  Should this combination
be permitted?</P>

<BR><BR><HR><A NAME="609"></A><H4>609.
  
What is a &#8220;top-level&#8221; cv-qualifier?
</H4><B>Section: </B>7.1.6.1&#160; [dcl.type.cv]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Dawn Perchik
 &#160;&#160;&#160;

 <B>Date: </B>5 November 2006<BR>


<P>The phrase &#8220;top-level cv-qualifier&#8221; is used numerous
times in the Standard, but it is not defined.  The phrase could be
misunderstood to indicate that the <TT>const</TT> in something like
<TT>const T&amp;</TT> is at the &#8220;top level,&#8221; because
where it appears is the highest level at which it is permitted:
<TT>T&amp; const</TT> is ill-formed.</P>

<BR><BR><HR><A NAME="144"></A><H4>144.
  
Position of <TT>friend</TT> specifier
</H4><B>Section: </B>7.1.6.3&#160; [dcl.type.elab]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>22 Jul 1999<BR>





<P>7.1.6.3 [dcl.type.elab]
 paragraph 1 seems to
impose an ordering constraint on the elements of friend class
declarations.  However, the general rule is that declaration
specifiers can appear in any order.  Should</P>

<PRE>
    class C friend;
</PRE>

be well-formed?
<BR><BR><HR><A NAME="1670"></A><H4>1670.
  
<TT>auto</TT> as <I>conversion-type-id</I>
</H4><B>Section: </B>7.1.6.4&#160; [dcl.spec.auto]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-26<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#FI4">N3690 comment
  FI&#160;4<BR></A>



<P>The current wording allows something like</P>

<PRE>
  struct S {
    operator auto() { return 0; }
  } s;
</PRE>

<P>If it is intended to be permitted, the details of its handling
are not clear.  Also, a similar syntax has been discussed as a
possible future extension for dealing with proxy types in deduction
which, if adopted, could cause confusion.</P>

<BR><BR><HR><A NAME="1766"></A><H4>1766.
  
Values outside the range of the values of an enumeration
</H4><B>Section: </B>7.2&#160; [dcl.enum]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>CWG
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-23<BR>


<P>Although <A HREF="
     cwg_defects.html#1094">issue 1094</A> clarified that the value
of an expression of enumeration type might not be within the range of the
values of the enumeration after a conversion to the enumeration type (see
5.2.9 [expr.static.cast] paragraph 10), the result is simply an
unspecified value.  This should probably be strengthened to produce
undefined behavior, in light of the fact that undefined behavior makes an
expression non-constant.  See also 9.6 [class.bit] paragraph 4.</P>

<BR><BR><HR><A NAME="987"></A><H4>987.
  
Which declarations introduce namespace members?
</H4><B>Section: </B>7.3&#160; [basic.namespace]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>19 October, 2009<BR>


<P>According to 7.3 [basic.namespace] paragraph 1,</P>

<BLOCKQUOTE>

The name of a namespace can be used to access entities
declared in that namespace; that is, the members of the
namespace.

</BLOCKQUOTE>

<P>implying that all declarations in a namespace, including
definitions of members of nested namespaces, explicit instantiations,
and explicit specializations, introduce members of the containing
namespace.  7.3.1.2 [namespace.memdef] paragraph 3 clarifies the
intent somewhat:</P>

<BLOCKQUOTE>

Every name first declared in a namespace is a member of that namespace.

</BLOCKQUOTE>

<P>However, current changes to clarify the behavior of deleted
functions (which must be deleted on their &#8220;first
declaration&#8221;) state that an explicit specialization of a
function template is its first declaration.</P>

<BR><BR><HR><A NAME="1795"></A><H4>1795.
  
Disambiguating <I>original-namespace-definition</I> and <I>extension-namespace-definition</I>
</H4><B>Section: </B>7.3.1&#160; [namespace.def]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-10-04<BR>


<P>According to 7.3.1 [namespace.def] paragraph 2,</P>

<BLOCKQUOTE>

The <I>identifier</I> in an <I>original-namespace-definition</I> shall not
have been previously defined in the declarative region in which
the <I>original-namespace-definition</I> appears.

</BLOCKQUOTE>

<P>Apparently the intent of this requirement is to say that, given the
declarations</P>

<PRE>
  namespace N { }
  namespace N { }
</PRE>

<P>the second declaration is to be taken as
an <I>extension-namespace-definition</I> and not an
<I>original-namespace-definition</I>, since the general rules in
3.3.1 [basic.scope.declarative] cover the case in which the <I>identifier</I>
has been previously declared as something other than a namespace.</P>

<P>This use of &#8220;shall&#8221; for disambiguation is novel,
however, and it would be better to replace it with a specific statement
addressing disambiguation in paragraphs 2 and 3.</P>

<BR><BR><HR><A NAME="1021"></A><H4>1021.
  
Definitions of namespace members
</H4><B>Section: </B>7.3.1.2&#160; [namespace.memdef]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2010-01-14<BR>


<P>According to 7.3.1.2 [namespace.memdef] paragraphs 1 and 2 read,</P>

<BLOCKQUOTE>

<P>Members (including explicit specializations of templates
(14.7.3 [temp.expl.spec])) of a namespace can be defined
within that namespace.</P>

<P>Members of a named namespace can also be defined outside that
namespace by explicit qualification (3.4.3.2 [namespace.qual]) of the name being defined, provided that the
entity being defined was already declared in the namespace and
the definition appears after the point of declaration in a
namespace that encloses the declaration's namespace.</P>

</BLOCKQUOTE>

<P>It is not clear what these specifications mean for the
following pair of examples:</P>

<PRE>
    namespace N {
        struct A;
    }
    using N::A;
    struct A { };
</PRE>

<P>Although this does not satisfy the &#8220;by explicit
qualification&#8221; requirement, it is accepted by major
implementations.</P>

<PRE>
    struct S;
    namespace A {
        using ::S;
        struct S  { };
    }
</PRE>

<P>Is this a definition &#8220;within that namespace,&#8221; or
should that wording be interpreted as &#8220;directly within&#8221;
the namespace?</P>

<BR><BR><HR><A NAME="36"></A><H4>36.
  
<I>using-declaration</I>s in multiple-declaration contexts
</H4><B>Section: </B>7.3.3&#160; [namespace.udecl]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Andrew Koenig
 &#160;&#160;&#160;

 <B>Date: </B>20 Aug 1998<BR>





<P>Section 7.3.3 [namespace.udecl]
 paragraph 8 says:</P>
<BLOCKQUOTE>A <I>using-declaration</I> is a declaration and can therefore be used
repeatedly where (and only where) multiple declarations are allowed.</BLOCKQUOTE>
It contains the following example:
<PRE>
    namespace A {
            int i;
    }
    
    namespace A1 {
            using A::i;
            using A::i;             // OK: double declaration
    }
    
    void f()
    {
            using A::i;
            using A::i;             // error: double declaration
    }
</PRE>
However, if "<TT>using A::i;</TT>" is really a declaration, and not a definition, it is far from clear that repeating it should be an error in either context.
Consider:
<PRE>
    namespace A {
            int i;
            void g();
    }
    
    void f() {
            using A::g;
            using A::g;
    }
</PRE>
Surely the definition of f should be analogous to
<PRE>
    void f() {
            void g();
            void g();
    }
</PRE>
which is well-formed because "<TT>void g();</TT>" is a declaration and
not a definition.

<P>Indeed, if the double using-declaration for <TT>A::i</TT> is prohibited
in <TT>f</TT>, why should it be allowed in namespace <TT>A1</TT>?</P>

<P><B>Proposed Resolution (04/99):</B>

Change the comment "<TT>// error: double declaration</TT>" to
"<TT>// OK: double declaration</TT>".

(This should be reviewed against existing practice.)</P>

<P><B>Notes from 04/00 meeting:</B></P>

<P>The core language working group was unable to come to consensus
over what kind of declaration a <I>using-declaration</I> should
emulate.  In a straw poll, 7 members favored allowing
<I>using-declaration</I>s wherever a non-definition declaration could
appear, while 4 preferred to allow multiple <I>using-declaration</I>s
only in namespace scope (the rationale being that the permission for
multiple <I>using-declaration</I>s is primarily to support its use in
multiple header files, which are seldom included anywhere other than
namespace scope).  John Spicer pointed out that <TT>friend</TT>
declarations can appear multiple times in class scope and asked if
<I>using-declaration</I>s would have the same property under the "like
a declaration" resolution.</P>

<P>As a result of the lack of agreement, the issue was returned to
"open" status.  </P>

<P>See also issues
<A HREF="
     cwg_defects.html#56">56</A>, <A HREF="
     cwg_defects.html#85">85</A>,
and <A HREF="
     cwg_active.html#138">138</A>..</P>

<P><B>Additional notes (January, 2005):</B></P>

<P>Some related issues have been raised concerning the following
example (modified from a C++ validation suite test):</P>

<PRE>
    struct A
    {
        int i;
        static int j;
    };

    struct B : A { };
    struct C : A { };

    struct D : virtual B, virtual C
    {
        using B::i;
        using C::i;
        using B::j;
        using C::j;
    };
</PRE>

<P>Currently, it appears that the <I>using-declaration</I>s of
<TT>i</TT> are ill-formed, on the basis of 7.3.3 [namespace.udecl] paragraph 10:</P>

<BLOCKQUOTE>

Since a <I>using-declaration</I> is a declaration, the
restrictions on declarations of the same name in the same
declarative region (3.3 [basic.scope]) also apply to
<I>using-declaration</I>s.

</BLOCKQUOTE>

<P>Because the <I>using-declaration</I>s of <TT>i</TT> refer to
different objects, declaring them in the same scope is not
permitted under 3.3 [basic.scope].  It might, however,
be preferable to treat this case as many other ambiguities are:
allow the declaration but make the program ill-formed if a name
reference resolves to the ambiguous declarations.</P>

<P>The status of the <I>using-declaration</I>s of <TT>j</TT>,
however, is less clear.  They both declare the same entity and
thus do not violate the rules of 3.3 [basic.scope].
This might (or might not) violate the restrictions of
9.2 [class.mem] paragraph 1:</P>

<BLOCKQUOTE>

Except when used to declare friends (11.3 [class.friend])
or to introduce the name of a member of a base class into a
derived class (7.3.3 [namespace.udecl], _N3225_.11.3 [class.access.dcl]), <I>member-declaration</I>s declare members of the
class, and each such member-declaration shall declare at least
one member name of the class. A member shall not be declared
twice in the <I>member-specification</I>, except that a nested
class or member class template can be declared and then later
defined.

</BLOCKQUOTE>

<P>Do the <I>using-declaration</I>s of <TT>j</TT> repeatedly
declare the same member?  Or is the preceding sentence an
indication that a <I>using-declaration</I> is not a declaration
of a member?</P>

<BR><BR><HR><A NAME="813"></A><H4>813.
  
<TT>typename</TT> in a <I>using-declaration</I> with a non-dependent name
</H4><B>Section: </B>7.3.3&#160; [namespace.udecl]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>UK
 &#160;&#160;&#160;

 <B>Date: </B>3 March, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#UK101">N2800 comment
  UK&#160;101<BR></A>

<P>7.3.3 [namespace.udecl] paragraph 20 says,</P>

<BLOCKQUOTE>

If a <I>using-declaration</I> uses the keyword <TT>typename</TT> and
specifies a dependent name (14.6.2 [temp.dep]), the name
introduced by the <I>using-declaration</I> is treated as a
<I>typedef-name</I> (7.1.3 [dcl.typedef]).

</BLOCKQUOTE>

<P>This wording does not address use of <TT>typename</TT> in a
<I>using-declaration</I> with a non-dependent name; the primary
specification of the <TT>typename</TT> keyword in 14.6 [temp.res] does not appear to describe this case, either.</P>

<BR><BR><HR><A NAME="852"></A><H4>852.
  
<I>using-declaration</I>s and dependent base classes
</H4><B>Section: </B>7.3.3&#160; [namespace.udecl]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2 April, 2009<BR>


<P>The status of an example like the following is unclear in the current
Standard:</P>

<PRE>
    struct B {
        void f();
    };
    template&lt;typename T&gt; struct S: T {
        using B::f;
    };
</PRE>

<P>7.3.3 [namespace.udecl] does not deal explicitly with dependent
base classes, but does say in paragraph 3,</P>

<BLOCKQUOTE>

In a <I>using-declaration</I> used as a <I>member-declaration</I>, the
<I>nested-name-specifier</I> shall name a base class of the class
being defined. If such a <I>using-declaration</I> names a constructor,
the <I>nested-name-specier</I> shall name a direct base class of the
class being defined; otherwise it introduces the set of declarations
found by member name lookup (10.2 [class.member.lookup], 3.4.3.1 [class.qual]).

</BLOCKQUOTE>

<P>In the definition of <TT>S</TT>, <TT>B::f</TT> is not a dependent
name but resolves to an apparently unrelated class.  However, because
<TT>S</TT> could be instantiated as <TT>S&lt;B&gt;</TT>, presumably
14.6 [temp.res] paragraph 8 would apply:</P>

<BLOCKQUOTE>

No diagnostic shall be issued for a template definition for which a
valid specialization can be generated.

</BLOCKQUOTE>

<P>Note also the resolution of <A HREF="
     cwg_defects.html#515">issue 515</A>,
which permitted a similar use of a dependent base class named with a
non-dependent name.</P>

<BR><BR><HR><A NAME="1742"></A><H4>1742.
  
<I>using-declaration</I>s and scoped enumerators
</H4><B>Section: </B>7.3.3&#160; [namespace.udecl]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-08-28<BR>




<P>A <I>using-declaration</I> cannot name a scoped enumerator, according
to 7.3.3 [namespace.udecl] paragraph 7.  This is presumably because
a scoped enumerator belongs to an enumeration scope and thus logically
cannot belong to the non-enumeration scope in which the
<I>using-declaration</I> appears.  It seems inconsistent, however, to
permit <I>using-declaration</I>s to name unscoped enumerators but not
scoped enumerators.</P>

<P>Also, 7.3.3 [namespace.udecl] paragraph 3 says,</P>

<BLOCKQUOTE>

In a <I>using-declaration</I> used as a <I>member-declaration</I>,
the <I>nested-name-specifier</I> shall name a base class of the class being
defined.

</BLOCKQUOTE>

<P>The consequence of this is that</P>

<PRE>
  enum E { e0 };
  void f() {
    using E::e0;
  }
</PRE>

<P>is well-formed, but</P>

<PRE>
  struct B {
    enum E { e0 };
  };
  struct D : B {
    using B::E::e0;
  };
</PRE>

<P>is not.  Again, this seems inconsistent.  Should these rules be
relaxed?</P>



<BR><BR><HR><A NAME="563"></A><H4>563.
  
Linkage specification for objects
</H4><B>Section: </B>7.5&#160; [dcl.link]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>8 March 2006<BR>


<P>It is not clear whether some of the wording in 7.5 [dcl.link]
that applies only to function types and names ought also to apply to
object names.  In particular, paragraph 3 says,</P>

<BLOCKQUOTE>

Every implementation shall provide for linkage to functions written in
the C programming language, <TT>"C"</TT>, and linkage to C++
functions, <TT>"C++"</TT>.

</BLOCKQUOTE>

<P>Nothing is said about variable names, apparently meaning that
implementations need not provide C (or even C++!) linkage for
variable names.  Also, paragraph 5 says,</P>

<BLOCKQUOTE>

Except for functions with C++ linkage, a function declaration without
a linkage specification shall not precede the first linkage
specification for that function. A function can be declared without a
linkage specification after an explicit linkage specification has been
seen; the linkage explicitly specified in the earlier declaration is
not affected by such a function declaration.

</BLOCKQUOTE>

<P>There doesn't seem to be a good reason for these provisions not
to apply to variable names, as well.</P>

<BR><BR><HR><A NAME="1713"></A><H4>1713.
  
Linkage of variable template specializations
</H4><B>Section: </B>7.5&#160; [dcl.link]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-07-08<BR>




<P>Given a namespace-scope declaration like</P>

<PRE>
  template&lt;typename T&gt; T var = T();
</PRE>

<P>should <TT>T&lt;const int&gt;</TT> have internal linkage by virtue
of its const-qualified type?  Or should it inherit the linkage of the
template?</P>

<BR><BR><HR><A NAME="1706"></A><H4>1706.
  
<TT>alignas</TT> pack expansion syntax
</H4><B>Section: </B>7.6.1&#160; [dcl.attr.grammar]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2013-06-26<BR>


<P>The grammar for <I>alignment-specifier</I> in 7.6.1 [dcl.attr.grammar]
paragraph 1 is:</P>

<UL><I>alignment-specifier:</I>
<UL><TT>alignas (</TT> <I>type-id</I> <TT>...</TT><I><SUB>opt</SUB></I><TT>)</TT><BR>
<TT>alignas (</TT> <I>assignment-expression</I> <TT>...</TT><I><SUB>opt</SUB></I><TT>)</TT>

</UL>

</UL>

<P>where the ellipsis indicates pack expansion.  Naively, one would expect
that the expansion would result in forms like</P>

<PRE>
    alignas()
    alignas(1, 2)
    alignas(int, double) 
</PRE>

<P>but none of those forms is given any meaning by the current wording.
Instead, 14.5.3 [temp.variadic] paragraph 4 says,</P>

<BLOCKQUOTE>

In an <I>alignment-specifier</I> (7.6.2 [dcl.align]); the pattern
is the <I>alignment-specifier</I> without the ellipsis.

</BLOCKQUOTE>

<P>Presumably this means that something like <TT>alignas(T...)</TT> would
expand to something like</P>

<PRE>
    alignas(int) alignas(double)
</PRE>

<P>This is counterintuitive and should be reexamined.</P>



<P>See also messages <A href="
   http://accu.org/cgi-bin/wg21/message?wg=core&amp;msg=24016">24016</A> through <A href="
   http://accu.org/cgi-bin/wg21/message?wg=core&amp;msg=24021">24021</A>.</P>

<BR><BR><HR><A NAME="1617"></A><H4>1617.
  
<TT>alignas</TT> and non-defining declarations
</H4><B>Section: </B>7.6.2&#160; [dcl.align]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2012-02-02<BR>




<P>According to 7.6.2 [dcl.align] paragraph 6,</P>

<BLOCKQUOTE>

If the defining declaration of an entity has an <I>alignment-specifier</I>,
any non-defining declaration of that entity shall either specify equivalent
alignment or have no <I>alignment-specifier</I>. Conversely, if any
declaration of an entity has an <I>alignment-specifier</I>, every defining
declaration of that entity shall specify an equivalent alignment. No
diagnostic is required if declarations of an entity have
different <I>alignment-specifier</I>s in different translation units.

</BLOCKQUOTE>

<P>Because this is phrased in terms of the definition of an entity,
an example like the following is presumably well-formed (even though
there can be no definition of <TT>n</TT>):</P>

<PRE>
   alignas(8) extern int n;
   alignas(16) extern int n;
</PRE>

<P>Is this intentional?</P>

<BR><BR><HR><A NAME="504"></A><H4>504.
  
Should use of a variable in its own initializer require a diagnostic?
</H4><B>Section: </B>8.3.2&#160; [dcl.ref]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Bjarne Stroustrup
 &#160;&#160;&#160;

 <B>Date: </B>14 Apr 2005<BR>


<P> Split
off from <A HREF="
     cwg_active.html#453">issue 453</A>.</P>

<P>It is in general not possible to determine at compile time whether
a reference is used before it is initialized.  Nevertheless, there is
some sentiment to require a diagnostic in the obvious cases that can
be detected at compile time, such as the name of a reference appearing
in its own initializer.  The resolution of <A HREF="
     cwg_active.html#453">issue 453</A> originally made such uses ill-formed, but the CWG decided
that this question should be a separate issue.</P>

<P><B>Rationale (October, 2005):</B></P>

<P>The CWG felt that this error was not likely to arise very
often in practice.  Implementations can warn about such constructs,
and the resolution for <A HREF="
     cwg_active.html#453">issue 453</A> makes
executing such code undefined behavior; that seemed to address the
situation adequately.</P>

<P><B>Note (February, 2006):</B></P>

<P>Recent discussions  have suggested that undefined behavior be
reduced.  One possibility (broadening the scope of this issue to
include object declarations as well as references) was to require a
diagnostic if the initializer uses the value, but not just the
address, of the object or reference being declared:</P>

<PRE>
    int i = i;        //<SPAN style="font-family:Times;font-style:italic"> Ill-formed, diagnostic required</SPAN>
    void* p = &amp;p;     //<SPAN style="font-family:Times;font-style:italic"> Okay</SPAN>
</PRE>

<BR><BR><HR><A NAME="393"></A><H4>393.
  
Pointer to array of unknown bound in template argument list in parameter
</H4><B>Section: </B>8.3.5&#160; [dcl.fct]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mark Mitchell
 &#160;&#160;&#160;

 <B>Date: </B>12 Dec 2002<BR>


<P>EDG rejects this code:
<PRE>
  template &lt;typename T&gt;
  struct S {};

  void f (S&lt;int (*)[]&gt;);
</PRE>
G++ accepts it.</P>

<P>This is another case where the standard isn't very clear:</P>

<P>The language from 8.3.5 [dcl.fct] is:
 <BLOCKQUOTE>
   If the type of a parameter includes a type of the form "pointer to
   array of unknown bound of T" or "reference to array of unknown bound
   of T," the program is ill-formed.
 </BLOCKQUOTE>
 Since "includes a type" is not a term defined in the standard, we're
 left to guess what this means.  (It would be better if this were a
 recursive definition, the way a type theoretician would do it:
 <UL>
 <LI> Every type includes itself. </LI>
 <LI> T* includes T </LI>
 <LI> T[] includes T </LI>
 <LI> ... </LI>
 </UL>
 )
 </P>

<P><B>Notes from April 2003 meeting:</B></P>

<P>We agreed that the example should be allowed.</P>

<P><B>Additional note (January, 2013):</B></P>

<P>Additional discussion of this issue has arisen
.  For
example, the following is permissible:</P>

<PRE>
  T (*p) [] = (U(*)[])0;
</PRE>

<P>but the following is not:</P>

<PRE>
  template&lt;class T&gt;
  void sp_assert_convertible( T* ) {}

  sp_assert_convertible&lt;T[]&gt;( (U(*)[])0 );
</PRE>



<BR><BR><HR><A NAME="550"></A><H4>550.
  
Pointer to array of unknown bound in parameter declarations
</H4><B>Section: </B>8.3.5&#160; [dcl.fct]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>22 November 2005<BR>


<P>The current wording of 8.3.5 [dcl.fct] paragraph 6
encompasses more than it should:</P>

<BLOCKQUOTE>

If the type of a parameter includes a type of the form &#8220;pointer
to array of unknown bound of <TT>T</TT>&#8221; or &#8220;reference to
array of unknown bound of <TT>T</TT>,&#8221; the program is
ill-formed. [<I>Footnote:</I> This excludes parameters of type
&#8220;<I>ptr-arr-seq</I> <TT>T2</TT>&#8221; where <TT>T2</TT> is
&#8220;pointer to array of unknown bound of <TT>T</TT>&#8221; and
where <I>ptr-arr-seq</I> means any sequence of &#8220;pointer
to&#8221; and &#8220;array of&#8221; derived declarator types. This
exclusion applies to the parameters of the function, and if a
parameter is a pointer to function or pointer to member function then
to its parameters also, etc. &#8212;<I>end footnote</I>]

</BLOCKQUOTE>

<P>The normative wording (contrary to the intention expressed in the
footnote) excludes declarations like</P>

<PRE>
    template&lt;class T&gt; struct S {};
    void f(S&lt;int (*)[]&gt;);
</PRE>

<P>and</P>

<PRE>
    struct S {};
    void f(int(*S::*)[]);
</PRE>

<P>but not</P>

<PRE>
    struct S {};
    void f(int(S::*)[]);
</PRE>

<BR><BR><HR><A NAME="1790"></A><H4>1790.
  
Ellipsis following function parameter pack
</H4><B>Section: </B>8.3.5&#160; [dcl.fct]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daryle Walker
 &#160;&#160;&#160;

 <B>Date: </B>2013-10-01<BR>


<P>Although the current wording permits an ellipsis to immediately follow a
function parameter pack, it is not clear that the <TT>&lt;cstdarg&gt;</TT>
facilities permit access to the ellipsis arguments.</P>

<BR><BR><HR><A NAME="361"></A><H4>361.
  
Forward reference to default argument
</H4><B>Section: </B>8.3.6&#160; [dcl.fct.default]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Clamage
 &#160;&#160;&#160;

 <B>Date: </B>17 June 2002<BR>




<P>Is this program well-formed?</P>
<PRE>
  struct S {
    static int f2(int = f1()); // OK?
    static int f1(int = 2);
  };
  int main()
  {
    return S::f2();
  }
</PRE>
<P>A class member function can in general refer to class members that
are declared lexically later.  But what about referring to default
arguments of member functions that haven't yet been declared?</P>

<P>It seems to me that if f2 can refer to f1, it can also refer to the
default argument of f1, but at least one compiler disagrees.</P>

<P><B>Notes from the February, 2012 meeting:</B></P>

<P>Implementations seem to have come to agreement that this example
is ill-formed.</P>

<P><B>Additional note (March, 2013):</B></P>

<P>Additional discussion has occurred  suggesting
the following examples as illustrations of this issue:</P>

<PRE>
  struct B {
   struct A { int a = 0; };
   B(A = A());    //<SPAN style="font-family:Times;font-style:italic"> Not permitted?</SPAN>
  };
</PRE>

<P>as well as</P>

<PRE>
  struct C {
   struct A { int a = C().n; }; //<SPAN style="font-family:Times;font-style:italic"> can we use the default argument here?</SPAN>
   C(int k = 0);
   int n;
  };

  bool f();
  struct D {
   struct A { bool a = noexcept(B()); }; //<SPAN style="font-family:Times;font-style:italic"> can we use the default initializer here?</SPAN>
   struct B { int b = f() ? throw 0 : 0; };
  };
</PRE>

<P>(See also <A HREF="
     cwg_active.html#325">issue 325</A>.)</P>

<P><B>Additional note (October, 2013):</B></P>

<P><A HREF="
     cwg_defects.html#1330">Issue 1330</A> treats
<I>exception-specification</I>s like default arguments, evaluated in the
completed class type.  That raises the same questions regarding
self-referential <TT>noexcept</TT> clauses that apply to default
arguments.</P>

<BR><BR><HR><A NAME="1609"></A><H4>1609.
  
Default arguments and function parameter packs
</H4><B>Section: </B>8.3.6&#160; [dcl.fct.default]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jonathan Caves
 &#160;&#160;&#160;

 <B>Date: </B>2013-01-25<BR>




<P>It is not clear from 8.3.6 [dcl.fct.default] whether the
following is well-formed or not:</P>

<PRE>
  template&lt;typename... T&gt;
  void f2(int a = 0, T... b, int c = 1);

  f2&lt;&gt;(); //<SPAN style="font-family:Times;font-style:italic"> parameter </SPAN>a<SPAN style="font-family:Times;font-style:italic"> has the value </SPAN>0<SPAN style="font-family:Times;font-style:italic"> and parameter </SPAN>c<SPAN style="font-family:Times;font-style:italic"> has the value </SPAN>1
</PRE>

<P>(<TT>T... b</TT> is a non-deduced context per
14.8.2.5 [temp.deduct.type] paragraph 5, so the template arguments must
be specified explicitly.)</P>

<P><B>Notes from the April, 2013 meeting:</B></P>

<P>CWG agreed that the example should be ill-formed.</P>

<P><B>Additional note (August, 2013):</B></P>

<P>8.3.6 [dcl.fct.default] paragraph 4 explicitly allows for a function
parameter pack to follow a parameter with a default argument:</P>

<BLOCKQUOTE>

In a given function declaration, each parameter subsequent to a parameter
with a default argument shall have a default argument supplied in this or a
previous declaration or shall be a function parameter pack.

</BLOCKQUOTE>

<P>However, any instantiation of such a function template with a non-empty
pack expansion would result in a function declaration in which one or more
parameters without default arguments (from the pack expansion) would follow
a parameter with a default argument and thus would be ill-formed.  Such a
function template declaration thus violates 14.6 [temp.res]
paragraph 8:</P>

<BLOCKQUOTE>

If every valid specialization of a variadic template requires an empty
template parameter pack, the template is ill-formed, no diagnostic
required.

</BLOCKQUOTE>

<P>Although the drafting review teleconference of 2013-08-26 suggested
closing the issue as NAD, it is being kept open to discuss and resolve this
apparent contradiction.  </P>

<P><B>Notes from the September, 2013 meeting:</B></P>

<P>CWG agreed that this example should be accepted; the restriction on
default arguments applies to the template declaration itself, not to
its specializations.</P>

<BR><BR><HR><A NAME="1791"></A><H4>1791.
  
Incorrect restrictions on <I>cv-qualifier-seq</I> and <I>ref-qualifier</I>
</H4><B>Section: </B>8.4.1&#160; [dcl.fct.def.general]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>David Krauss
 &#160;&#160;&#160;

 <B>Date: </B>2013-10-01<BR>


<P>Paragraph 5 of 8.4.1 [dcl.fct.def.general] says,</P>

<BLOCKQUOTE>

A <I>cv-qualifier-seq</I> or a <I>ref-qualifier</I> (or both) can be part
of a non-static member function declaration, non-static member function
definition, or pointer to member function only
(8.3.5 [dcl.fct]); see 9.3.2 [class.this].

</BLOCKQUOTE>

<P>This is redundant with the specification in 8.3.5 [dcl.fct]
paragraph 6 and is factually incorrect, since the list there contains
other permissible constructs.  It should be at most a note or possibly
removed altogether.</P>

<BR><BR><HR><A NAME="670"></A><H4>670.
  
Copy initialization via derived-to-base conversion in the second step
</H4><B>Section: </B>8.5&#160; [dcl.init]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>20 December 2007<BR>




<P>In this example:</P>

<PRE>
    struct A {};

    struct B: A {
       B(int);
       B(B&amp;);
       B(A);
    };

    void foo(B);

    void bar() {
       foo(0);
    }
</PRE>

<P>we are copy-initializing a <TT>B</TT> from <TT>0</TT>. So by
13.3.1.4 [over.match.copy] we consider all the converting
constructors of <TT>B</TT>, and choose <TT>B(int)</TT> to create
a <TT>B</TT>.  Then, by 8.5 [dcl.init] paragraph 15, we
direct-initialize the parameter from that temporary <TT>B</TT>.  By
13.3.1.3 [over.match.ctor] we consider all constructors.  The copy
constructor cannot be called with a temporary, but <TT>B(A)</TT> is
callable.</P>

<P>As far as I can tell, the Standard says that this example is
well-formed, and calls <TT>B(A)</TT>.  EDG and G++ have rejected this
example with a message about the copy constructor not being callable,
but I have been unsuccessful in finding anything in the Standard that
says that we only consider the copy constructor in the second step of
copy-initialization.  I wouldn't mind such a rule, but it doesn't seem
to be there.  And implementing <A HREF="
     cwg_defects.html#391">issue 391</A>
causes G++ to start accepting the example.</P>

<P>This question came up before in
<A href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17431">a GCC bug
report</A>; in the discussion of that bug Nathan Sidwell said that
some EDG folks explained to him why the testcase is ill-formed, but
unfortunately didn't provide that explanation in the bug report.
</P>

<P>I think the resolution of <A HREF="
     cwg_defects.html#391">issue 391</A>
makes this example well-formed; it was previously ill-formed because
in order to bind the temporary <TT>B(0)</TT> to the argument of
<TT>A(const A&amp;)</TT> we needed to make another
temporary <TT>B</TT>, and that's what made the example ill-formed.  If
we want this example to stay ill-formed, we need to change something
else.</P>

<P><U>Steve Adamczyk:</U></P>

<P>I tracked down my response to Nathan at the time, and it related to
my paper N1232 (on the <TT>auto_ptr</TT> problem).  The change that
came out of that paper is in 13.3.3.1 [over.best.ics] paragraph
4:</P>

<BLOCKQUOTE>

However, when considering the argument of a user-defined conversion
function that is a candidate by 13.3.1.3 [over.match.ctor] when
invoked for the copying of the temporary in the second step of a class
copy-initialization, or by 13.3.1.4 [over.match.copy], 13.3.1.5 [over.match.conv], or 13.3.1.6 [over.match.ref] in all cases, only
standard conversion sequences and ellipsis conversion sequences are
allowed.

</BLOCKQUOTE>

<P>This is intended to prevent use of more than one implicit user-
defined conversion in an initialization.</P>

<P>I told Nathan <TT>B(A)</TT> can't be called because its argument
would require yet another user-defined conversion, but I was wrong.  I
saw the conversion from <TT>B</TT> to <TT>A</TT> and immediately
thought &#8220;user-defined,&#8221; but in fact because <TT>B</TT> is
a derived class of <TT>A</TT> the conversion according to 13.3.3.1 [over.best.ics] paragraph 6 is a derived-to-base Conversion (even
though it will be implemented by calling a copy constructor).</P>

<P>So I agree with you: with the analysis above and the change for
<A HREF="
     cwg_defects.html#391">issue 391</A> this example is well-formed.  We
should discuss whether we want to make a change to keep it
ill-formed.</P>

<BR><BR><HR><A NAME="1782"></A><H4>1782.
  
Form of initialization for <TT>nullptr_t</TT> to <TT>bool</TT> conversion
</H4><B>Section: </B>8.5&#160; [dcl.init]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2013-02-26<BR>


<P>According to 8.5 [dcl.init] paragraph 14,</P>

<BLOCKQUOTE>

The form of initialization (using parentheses or <TT>=</TT>) is generally
insignificant, but does matter when the initializer or the entity being
initialized has a class type; see below.

</BLOCKQUOTE>

<P>This does not consider conversions from <TT>std::nullptr_t</TT> to
<TT>bool</TT>, which are permitted only for direct-initialization
(4.12 [conv.bool]).</P>

<BR><BR><HR><A NAME="233"></A><H4>233.
  
References vs pointers in UDC overload resolution
</H4><B>Section: </B>8.5.3&#160; [dcl.init.ref]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Matthias Meixner
 &#160;&#160;&#160;

 <B>Date: </B>9 Jun 2000<BR>


<P>There is an inconsistency in the handling of references
vs pointers in user defined conversions and overloading. The reason
for that is that the combination of 8.5.3 [dcl.init.ref] and
4.4 [conv.qual] circumvents the standard way of ranking
conversion functions, which was probably not the intention of the
designers of the standard.</P>

<P>Let's start with some examples, to show what it is about:</P>

<PRE>
    struct Z { Z(){} };

    struct A {
       Z x;

       operator Z *() { return &amp;x; }
       operator const Z *() { return &amp;x; }
    };

    struct B {
       Z x;

       operator Z &amp;() { return x; }
       operator const Z &amp;() { return x; }
    };

    int main()
    {
       A a;
       Z *a1=a;
       const Z *a2=a; // not ambiguous

       B b;
       Z &amp;b1=b;
       const Z &amp;b2=b; // ambiguous
    }
</PRE>

<P>So while both classes <TT>A</TT> and <TT>B</TT> are structurally
equivalent, there is a difference in operator overloading. I want to
start with the discussion of the pointer case (<TT>const Z
*a2=a;</TT>): 13.3.3 [over.match.best] is used to select the best
viable function. Rule 4 selects <TT>A::operator const Z*()</TT> as
best viable function using 13.3.3.2 [over.ics.rank] since the
implicit conversion sequence <TT>const Z*</TT> -&gt; <TT>const Z*</TT>
is a better conversion sequence than <TT>Z*</TT> -&gt; <TT>const
Z*</TT>.</P>

<P>So what is the difference to the reference case?  Cv-qualification
conversion is only applicable for pointers according to 4.4 [conv.qual]. According to 8.5.3 [dcl.init.ref] paragraphs
4-7 references are initialized by binding using the concept of
reference-compatibility. The problem with this is, that in this
context of binding, there is no conversion, and therefore there is
also no comparing of conversion sequences. More exactly all
conversions can be considered identity conversions according to
13.3.3.1.4 [over.ics.ref] paragraph 1, which compare equal
and which has the same effect.  So binding <TT>const Z*</TT> to
<TT>const Z*</TT> is as good as binding <TT>const Z*</TT> to
<TT>Z*</TT> in terms of overloading. Therefore <TT>const Z
&amp;b2=b;</TT> is ambiguous.  [13.3.3.1.4 [over.ics.ref]
paragraph 5 and 13.3.3.2 [over.ics.rank] paragraph 3 rule 3
(S1 and S2 are reference bindings ...) do not seem to apply to this
case]</P>

<P>There are other ambiguities, that result in the special treatment
of references: Example:</P>

<PRE>
    struct A {int a;};
    struct B: public A { B() {}; int b;};

    struct X {
       B x;
       operator A &amp;() { return x; }
       operator B &amp;() { return x; }
    };

    main()
    {
       X x;
       A &amp;g=x; // ambiguous
    }
</PRE>

<P>Since both references of class <TT>A</TT> and <TT>B</TT> are
reference compatible with references of class <TT>A</TT> and since
from the point of ranking of implicit conversion sequences they are
both identity conversions, the initialization is ambiguous.
</P>

<P>So why should this be a defect?</P>

<UL>

<LI>References behave fundamentally different from pointers in combination 
with user defined conversions, although there is no reason to have this
different treatment.</LI>

<LI>This difference only shows up in combination with user defined
conversion sequences, for all other cases, there are special rules,
e.g. 13.3.3.2 [over.ics.rank] paragraph 3 rule 3.</LI>

</UL>

<P>So overall I think this was not the intention of the authors of the
standard.</P>

<P>So how could this be fixed? For comparing conversion sequences (and
only for comparing) reference binding should be treated as if it was a
normal assignment/initialization and cv-qualification would have to be
defined for references. This would affect 8.5.3 [dcl.init.ref] paragraph 6, 4.4 [conv.qual] and probably
13.3.3.2 [over.ics.rank] paragraph 3.</P>

<P>Another fix could be to add a special case in 13.3.3 [over.match.best] paragraph 1. </P>

<BR><BR><HR><A NAME="1650"></A><H4>1650.
  
Class prvalues in reference initialization
</H4><B>Section: </B>8.5.3&#160; [dcl.init.ref]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-15<BR>




<P>As described in the &#8220;additional note, January, 2012&#8221; in
<A HREF="
     cwg_defects.html#1287">issue 1287</A>, questions were raised regarding the
treatment of class prvalues in the original proposed resolution and the
proposed resolution was revised (February, 2012) to address those concerns.
The revised resolution raised its own set of concerns with regard to
slicing and performance, however, and the issue was moved back to "review"
status to allow further discussion. 
</P>

<P>At the April, 2013 meeting, it was decided to proceed with the original
resolution of <A HREF="
     cwg_defects.html#1287">issue 1287</A> and split off the
concerns regarding class prvalues into this issue.</P>



<P><B>Notes from the September, 2013 meeting:</B></P>

<P>The resolution for <A HREF="
     cwg_active.html#1604">issue 1604</A> results in
indirect binding to a subobject and will no longer cause slicing.</P>

<BR><BR><HR><A NAME="1599"></A><H4>1599.
  
Lifetime of <TT>initializer_list</TT> underlying array
</H4><B>Section: </B>8.5.4&#160; [dcl.init.list]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2012-02-10<BR>




<P>The normative wording of 8.5.4 [dcl.init.list] regarding the
lifetime of the array underlying an <TT>initializer_list</TT> object
does not match the intent as specified in the example in paragraph 6
of that section, even after application of the resolution of
<A HREF="
     cwg_defects.html#1290">issue 1290</A>.  That example contains the
lines:</P>

<PRE>
  void f() {
    std::initializer_list&lt;int&gt; i3 = { 1, 2, 3 };
  }
</PRE>

<P>The commentary indicates that the lifetime of the array created
for the initialization of <TT>i3</TT> &#8220;persists for the lifetime
of the variable.&#8221;  However, that is not the effect of the
normative wording.  According to paragraph 3,</P>

<BLOCKQUOTE>

if <TT>T</TT> is a specialization of
<TT>std::initializer_list&lt;E&gt;</TT>, an <TT>initializer_list</TT>
object is constructed as described below and used to initialize the
object according to the rules for initialization of an object from a
class of the same type (8.5 [dcl.init]).

</BLOCKQUOTE>

<P>In other words, the underlying array for <TT>{1,2,3}</TT> in
the example is associated with the temporary and shares its lifetime;
its lifetime is not extended to that of the variable.</P>



<BR><BR><HR><A NAME="1756"></A><H4>1756.
  
Direct-list-initialization of a non-class object
</H4><B>Section: </B>8.5.4&#160; [dcl.init.list]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-20<BR>




<P>The wording of 8.5.4 [dcl.init.list] paragraph 3,</P>

<BLOCKQUOTE>

if the initializer list has a single element of type <TT>E</TT> and
either <TT>T</TT> is not a reference type or its referenced type is
reference-related to <TT>E</TT>, the object or reference is initialized
from that element

</BLOCKQUOTE>

<P>does not specify whether the initialization is direct-initialization,
copy-initialization, or the same kind of initialization that applied to the
list-initialization.  This matters when <TT>E</TT> is a class type with an
explicit conversion function.  (Note that aggregate initialization performs
copy-initialization on its subobjects, but it's not clear whether that
should be the pattern followed for this case.)</P>

<BR><BR><HR><A NAME="511"></A><H4>511.
  
POD-structs with template assignment operators
</H4><B>Section: </B>9&#160; [class]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>19 Mar 2005<BR>


<P>A POD-struct is not permitted to have a user-declared copy
assignment operator (9 [class] paragraph 4).  However, a
template assignment operator is not considered a copy assignment
operator, even though its specializations can be selected by overload
resolution for performing copy operations (12.8 [class.copy]
paragraph 9 and especially footnote 114).  Consequently, <TT>X</TT> in
the following code is a POD, notwithstanding the fact that copy
assignment (for a non-const operand) is a member function call
rather than a bitwise copy:</P>

<PRE>
    struct X {
      template&lt;typename T&gt; const X&amp; operator=(T&amp;);
    };
    void f() {
      X x1, x2;
      x1 = x2;  //<SPAN style="font-family:Times;font-style:italic"> calls </SPAN>X::operator=&lt;X&gt;(X&amp;)
    }
</PRE>

<P>Is this intentional?</P>

<BR><BR><HR><A NAME="1660"></A><H4>1660.
  
<I>member-declaration</I> requirements and unnamed bit-fields
</H4><B>Section: </B>9.2&#160; [class.mem]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-15<BR>


<P>According to 9.2 [class.mem] paragraph 1,</P>

<BLOCKQUOTE>

Except when used to declare friends (11.3 [class.friend]) or to
introduce the name of a member of a base class into a derived class
(7.3.3 [namespace.udecl]), <I>member-declaration</I>s declare members of
the class, and each such <I>member-declaration</I> shall declare at least
one member name of the class.

</BLOCKQUOTE>

<P>Unnamed bit-fields (9.6 [class.bit] paragraph 2) are
described as not being members, and they obviously do not declare a
member name; presumably they should therefore be included among the
exceptions to this rule.</P>

<P>Additional note (October, 2013):</P>

<P>Curiously, the exemption for an unnamed bit-field not introducing
names is in 7 [dcl.dcl] paragraph 3, referring to a
<I>simple-declaration</I>.  However, a <I>simple-declaration</I> is
not a <I>member-declaration</I> and thus does not apply.</P>

<BR><BR><HR><A NAME="1719"></A><H4>1719.
  
Layout compatibility and cv-qualification revisited
</H4><B>Section: </B>9.2&#160; [class.mem]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jeffrey Yasskin
 &#160;&#160;&#160;

 <B>Date: </B>2013-07-24<BR>




<P>When the effect of cv-qualification on layout compatibility was
previously discussed (see <A HREF="
     cwg_closed.html#1334">issue 1334</A>), the
question was resolved by reference to the historical origin of layout
compatibility: it was a weakening of type correctness that was added for C
compatibility, mimicking exactly the corresponding C specification of
compatible types in this context and going no further.  Because
cv-qualified and cv-unqualified types are not compatible in C, they were
not made layout-compatible in C++.</P>

<P>Because of specific use-cases involving <TT>std::pair</TT> and the like,
however, and in consideration of the fact that cv-qualified and
cv-unqualified versions of types are aliasable by the rules of
3.10 [basic.lval], the outcome of that question is worthy of
reconsideration.</P>

<BR><BR><HR><A NAME="57"></A><H4>57.
  
Empty unions
</H4><B>Section: </B>9.5&#160; [class.union]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>13 Oct 1998<BR>



<P>There doesn't seem to be a prohibition in 9.5 [class.union]
 against a declaration
like</P>
<PRE>
    union { int : 0; } x;
</PRE>
Should that be valid?  If so, 8.5 [dcl.init]

paragraph 5 third bullet, which deals with
default-initialization of unions, should say that no initialization is
done if there are no data members.
    
<P>What about:</P>
<PRE>
    union { } x;
    static union { };
</PRE>
If the first example is well-formed, should either or both of these cases
be well-formed as well?

<P>(See also the resolution for
<A HREF="
     cwg_defects.html#151">issue 151</A>.)</P>

<P><B>Notes from 10/00 meeting:</B> The resolution to
<A HREF="
     cwg_defects.html#178">issue 178</A>, which was accepted as a
DR, addresses the first point above (default initialization).
The other questions have not yet been decided, however.</P>
<BR><BR><HR><A NAME="380"></A><H4>380.
  
Definition of "ambiguous base class" missing
</H4><B>Section: </B>10.2&#160; [class.member.lookup]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>22 Oct 2002<BR>


<P>The term "ambiguous base class" doesn't seem to be actually defined
anywhere.  10.2 [class.member.lookup] paragraph 7 seems like the place
to do it.</P>

<BR><BR><HR><A NAME="600"></A><H4>600.
  
Does access control apply to members or to names?
</H4><B>Section: </B>11&#160; [class.access]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>3 October 2006<BR>


<P>Referring to a private member of a class, 11 [class.access]
paragraph 1 says,</P>

<BLOCKQUOTE>

its name can be used only by members and friends of the class in which
it is declared.

</BLOCKQUOTE>

<P>That wording does not appear to reflect the intent of access control,
however.  Consider the following:</P>

<PRE>
    struct S {
        void f(int);
    private:
        void f(double);
    };

    void g(S* sp) {
        sp-&gt;f(2);        //<SPAN style="font-family:Times;font-style:italic"> Ill-formed?</SPAN>
    }
</PRE>

<P>The statement from 11 [class.access] paragraph 1 says that the
name <TT>f</TT> can be used only by members and friends of <TT>S</TT>.
Function <TT>g</TT> is neither, and it clearly contains a use of the
name <TT>f</TT>.  That appears to make it ill-formed, in spite of the fact
that overload resolution will select the public member.</P>

<P>A related question is whether the use of the term &#8220;name&#8221;
in the description of the effect of access control means that it does
not apply to constructors and destructors, which do not have names.</P>

<P><U>Mike Miller</U>: The phrase &#8220;its name can be used&#8221;
should be understood as &#8220;it can be referred to by name.&#8221;
Paragraph 4, among other places, makes it clear that access control is
applied after overload resolution.  The &#8220;name&#8221; phrasing is
there to indicate that access control does not apply where the name is
not used (in a call via a pointer, for example).</P>

<BR><BR><HR><A NAME="360"></A><H4>360.
  
Using-declaration that reduces access
</H4><B>Section: </B>11.2&#160; [class.access.base]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Clamage
 &#160;&#160;&#160;

 <B>Date: </B>4 June 2002<BR>




<P>I have heard a claim that the following code is valid, but I don't
see why.</P>
<PRE>
  struct A {
    int foo ();
  };

  struct B: A {
  private:
    using A::foo;
  };

  int main ()
  {
    return B ().foo ();
  }
</PRE>
<P>
It seems to me that the using declaration in B should hide the
public foo in A. Then the call to B::foo should fail because B::foo
is not accessible in main.</P>

<P>Am I missing something?</P>

<P><U>Steve Adamczyk</U>:
This is similar to the last example in 11.2 [class.access.base].
In prose, the rule is
that if you have access to cast to a base class and you have access
to the member in the base class, you are given access in the derived
class.  In this case, A is a public base class of B and foo is public
in A, so you can access foo through a B object.  The actual permission
for this is in the fourth bullet in
11.2 [class.access.base] paragraph 4.</P>

<P>The wording changes for <A HREF="
     cwg_defects.html#9">issue 9</A>
make this clearer, but I believe
even without them this example could be discerned to be valid.</P>

<P>See my paper J16/96-0034, WG21/N0852 on this topic.</P>

<P><U>Steve Clamage</U>:
But a using-declaration is a declaration (7.3.3 [namespace.udecl]).
Compare with</P>
<PRE>
  struct B : A {
  private:
    int foo();
  };
</PRE>
<P>In this case, the call would certainly be invalid, even though your
argument about casting B to an A would make it OK. Your argument
basically says that an access adjustment to make something less
accessible has no effect. That also doesn't sound right.</P>

<P><U>Steve Adamczyk</U>:
I agree that is strange.  I do think that's what 11.2 [class.access.base]
says, but perhaps that's not what we want it to say.</P>

<BR><BR><HR><A NAME="718"></A><H4>718.
  
Non-class, non-function friend declarations
</H4><B>Section: </B>11.3&#160; [class.friend]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>18 September, 2008<BR>


<P>With the change from a scope-based to an entity-based definition
of friendship (see issues <A HREF="
     cwg_defects.html#372">372</A> and
<A HREF="
     cwg_defects.html#580">580</A>), it could well make sense to
grant friendship to enumerations and variables, for example:</P>

<PRE>
    enum E: int;
    class C {
      static const int i = 5;  //<SPAN style="font-family:Times;font-style:italic"> Private</SPAN>
      friend E;
      friend int x;
    };
    enum E { e = C::i; };      //<SPAN style="font-family:Times;font-style:italic"> OK: </SPAN>E<SPAN style="font-family:Times;font-style:italic"> is a friend</SPAN>
    int x = C::i;              //<SPAN style="font-family:Times;font-style:italic"> OK: </SPAN>x<SPAN style="font-family:Times;font-style:italic"> is a friend</SPAN>
</PRE>

<P>According to the current wording of 11.3 [class.friend]
paragraph 3, the friend declaration of <TT>E</TT> is well-formed
but ignored, while the friend declaration of <TT>x</TT> is
ill-formed.</P>

<BR><BR><HR><A NAME="581"></A><H4>581.
  
Can a templated constructor be explicitly instantiated or specialized?
</H4><B>Section: </B>12.1&#160; [class.ctor]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mark Mitchell
 &#160;&#160;&#160;

 <B>Date: </B>19 May 2006<BR>


<P>Although it is not possible to specify a constructor's template
arguments in a constructor invocation (because the constructor has
no name but is invoked by use of the constructor's class's name), it
is possible to &#8220;name&#8221; the constructor in declarative
contexts: per 3.4.3.1 [class.qual] paragraph 2,</P>

<BLOCKQUOTE>

In a lookup in which the constructor is an acceptable lookup result,
if the <I>nested-name-specifier</I> nominates a class <TT>C</TT>, and
the name specified after the <I>nested-name-specifier</I>, when looked
up in <TT>C</TT>, is the injected-class-name of <TT>C</TT> (clause
9 [class]), the name is instead considered to name the
constructor of class <TT>C</TT>... Such a constructor name shall be
used only in the <I>declarator-id</I> of a declaration that names a
constructor.

</BLOCKQUOTE>

<P>Should it therefore be possible to specify <I>template-argument</I>s
for a templated constructor in an explicit instantiation or specialization?
For example,</P>

<PRE>
    template &lt;int dim&gt; struct T {};
    struct X {
      template &lt;int dim&gt; X (T&lt;dim&gt; &amp;) {};
    };

    template X::X&lt;&gt; (T&lt;2&gt; &amp;);
</PRE>

<P>If so, that should be clarified in the text.  In
particular, 12.1 [class.ctor] paragraph 1 says,</P>

<BLOCKQUOTE>

Constructors do not have names. A special declarator syntax using an
optional sequence of <I>function-specifier</I>s (7.1.2 [dcl.fct.spec]) followed by the constructor's class name followed by
a parameter list is used to declare or define the constructor.

</BLOCKQUOTE>

<P>This certainly sounds as if the parameter list must immediately
follow the class name, with no allowance for a template argument
list.</P>

<P>It would be worthwhile in any event to revise this wording
to utilize the &#8220;considered to name&#8221; approach of
3.4.3.1 [class.qual]; as it stands, this wording
sounds as if the following would be acceptable:</P>

<PRE>
    struct S {
        S();
    };
    S() { }    // <SPAN style="font-family:Times;font-style:italic">qualified-id</SPAN> not required?
</PRE>

<P><B>Notes from the October, 2006 meeting:</B></P>

<P>It was observed that explicitly specifying the template arguments
in a constructor declaration is never actually necessary because the
arguments are, by definition, all deducible and can thus be omitted.</P>

<BR><BR><HR><A NAME="1696"></A><H4>1696.
  
Temporary lifetime and non-static data member initializers
</H4><B>Section: </B>12.2&#160; [class.temporary]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-05-31<BR>




<P>Presumably a temporary bound to a reference in a non-static data member
initializer should be treated analogously with what happens in a
<I>ctor-initializer</I>, but the current wording of
12.2 [class.temporary] paragraph 5 is not clear on this point.</P>

<BR><BR><HR><A NAME="344"></A><H4>344.
  
Naming destructors
</H4><B>Section: </B>12.4&#160; [class.dtor]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jamie Schmeiser
 &#160;&#160;&#160;

 <B>Date: </B>25 April 2002<BR>


<P>Note that destructors suffer from similar problems as those of
constructors dealt with in <A HREF="
     cwg_defects.html#194">issue 194</A>
and in <A HREF="
     cwg_defects.html#263">263</A> (constructors as
friends).  Also, the wording in 12.4 [class.dtor],
paragraph 1 does not permit a
destructor to be defined outside of the memberlist.</P>

<P>Change 12.4 [class.dtor], paragraph 1 from</P>
<BLOCKQUOTE>
...A special declarator syntax using an optional <I>function-specifier</I>
(7.1.2 [dcl.fct.spec]) followed by <TT>~</TT> followed by
the destructor's class name followed
by an empty parameter list is used to declare the destructor in a
class definition.  In such a declaration, the <TT>~</TT> followed by the
destructor's class name can be enclosed in optional parentheses; such
parentheses are ignored....
</BLOCKQUOTE>
<P>to</P>
<BLOCKQUOTE>
...A special declarator syntax using an optional sequence of
<I>function-specifier</I>s (7.1.2 [dcl.fct.spec]),
an optional friend keyword, an optional
sequence of <I>function-specifier</I>s (7.1.2 [dcl.fct.spec])
followed by an optional <TT>::</TT>
scope-resolution-operator followed by an optional
<I>nested-name-specifier</I> followed by <TT>~</TT>
followed by the destructor's class
name followed by an empty parameter list is used to declare the
destructor.  The optional <I>nested-name-specifier</I> shall not be specified
in the declaration of a destructor within the member-list of the class
of which the destructor is a member.  In such a declaration, the
optional <TT>::</TT> scope-resolution-operator followed by an optional
<I>nested-name-specifier</I> followed by <TT>~</TT>
 followed by the destructor's class
name can be enclosed in optional parentheses; such parentheses are
ignored....
</BLOCKQUOTE>

<BR><BR><HR><A NAME="1783"></A><H4>1783.
  
Why are virtual destructors non-trivial?
</H4><B>Section: </B>12.4&#160; [class.dtor]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jeffrey Yasskin
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-26<BR>


<P>According to 12.4 [class.dtor] paragraph 5,</P>

<BLOCKQUOTE>

<P>A destructor is trivial if it is not user-provided and if:</P>

<UL><LI><P>the destructor is not <TT>virtual</TT>,</P></LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<P>It is not clear why this restriction is needed, and it should be
removed if it is not needed.</P>

<BR><BR><HR><A NAME="607"></A><H4>607.
  
Lookup of <I>mem-initializer-id</I>s
</H4><B>Section: </B>12.6.2&#160; [class.base.init]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Corden
 &#160;&#160;&#160;

 <B>Date: </B>5 December 2006<BR>




<P>In an example like,</P>

<PRE>
    struct Y {};

    template &lt;typename T&gt;
    struct X : public virtual Y { };

    template &lt;typename T&gt;
    class A : public X&lt;T&gt; {
      template &lt;typename S&gt;
      A (S)
        : S ()
      {
      }
    };

    template A&lt;int&gt;::A (Y);
</PRE>

<P>Should <TT>S</TT> be found?  (<TT>S</TT> is a dependent name, so
if it resolves to a base class type in the instantiated template, it
should satisfy the requirements.)  All the compilers I tried allowed
this example, but 12.6.2 [class.base.init] paragraph 2 says,</P>

<BLOCKQUOTE>

Names in a <I>mem-initializer-id</I> are looked up in the scope
of the constructor's class and, if not found in that scope, are
looked up in the scope containing the constructor's definition.

</BLOCKQUOTE>

<P>The name <TT>S</TT> is not declared in those scopes.</P>

<P><U>Mike Miller</U>: Here's another example that is accepted by
most/all compilers but not by the current wording:</P>

<PRE>
    namespace N {
      struct B { B(int); };
      typedef B typedef_B;
      struct D: B {
        D();
      };
    }

    N::D::D(): typedef_B(0) { }
</PRE>

<P>Except for the fact that the constructor function parameter
names are ignored (see paragraph 7), what the compilers seem to
be doing is essentially ordinary unqualified name lookup.</P>

<P><B>Notes from the October, 2009 meeting:</B></P>

<P>The eventual resolution of this issue should take into account the
template parameter scope introduced by the resolution of
<A HREF="
     cwg_defects.html#481">issue 481</A>.</P>

<BR><BR><HR><A NAME="1752"></A><H4>1752.
  
Right-recursion in <I>mem-initializer-list</I>
</H4><B>Section: </B>12.6.2&#160; [class.base.init]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Christof Meerwald
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-16<BR>




<P>The grammar for <I>mem-initializer-list</I> in 12.6.2 [class.base.init]
paragraph 1 (after the resolution of <A HREF="
     cwg_defects.html#1649">issue 1649</A>)
is right-recursive:</P>

<UL><I>mem-initializer-list:</I>
<UL><I>mem-initializer</I> <TT>...</TT><SUB><I>opt</I></SUB><BR>
<I>mem-initializer</I> <TT>...</TT><SUB><I>opt</I></SUB> <TT>,</TT> <I>mem-initializer-list</I>
</UL>
</UL>

<P>In general, however, such lists elsewhere in the Standard are described
using a left-recursive grammar, e.g., for <I>initializer-list</I> in
8.5 [dcl.init] paragraph 1:</P>

<UL><I>initializer-list:</I>
<UL><I>initializer-clause</I> <TT>...</TT><I><SUB>opt</SUB></I><BR>
<I>initializer-list</I> <TT>,</TT> <I>initializer-clause</I> <TT>...</TT><I><SUB>opt</SUB></I>
</UL>
</UL>

<P>It would be better to be consistent in the definition of
<I>mem-initializer-list</I>.</P>

<BR><BR><HR><A NAME="6"></A><H4>6.
  
Should the optimization that allows a class object to alias another object also allow the case of a parameter in an inline function to alias its argument?
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>unknown
 &#160;&#160;&#160;

 <B>Date: </B>unknown<BR>



<P>[Picked up by evolution group at October 2002 meeting.]</P>


 
(See also paper J16/99-0005 = WG21 N1182.)

<P>At the London meeting,
12.8 [class.copy]
 paragraph 31 was changed to
limit the optimization described to only the following cases:</P>
<UL>
<LI>
the source is a temporary object</LI>
    
<LI>
the return value optimization</LI>
</UL>
One other case was deemed desirable as well:
<UL>
<LI>
aliasing a parameter in an inline function call to the function call argument.</LI>
</UL>
However, there are cases when this aliasing was deemed undesirable and,
at the London meeting, the committee was not able to clearly delimit which
cases should be allowed and which ones should be prohibited.
    
<P>Can we find an appropriate description for the desired cases?</P>
    
<P><B>Rationale (04/99):</B> The absence of this optimization does
not constitute a defect in the Standard,
although the proposed resolution in the paper
should be considered when the Standard is revised.</P>

<P><B>Note (March, 2008):</B></P>

<P>The Evolution Working Group has accepted the intent of this issue and
referred it to CWG for action (not for C++0x).  See paper J16/07-0033 =
WG21 N2173.</P>

<P><B>Notes from the June, 2008 meeting:</B></P>

<P>The CWG decided to take no action on this issue until an interested
party produces a paper with analysis and a proposal.</P>
<BR><BR><HR><A NAME="1049"></A><H4>1049.
  
Copy elision through reference parameters of inline functions
</H4><B>Section: </B>12.8&#160; [class.copy]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-10<BR>




<P>Consider the following example:</P>

<PRE>
    int c;

    struct A {
       A() { ++c; }
       A(const A&amp;) { ++c; }
    };

    struct B {
       A a;
       B(const A&amp; a): a(a) { }
    };

    int main() {
       (B(A()));
       return c - 1;
    }
</PRE>

<P>Here we would like to be able to avoid the copy and just
construct the <TT>A()</TT> directly into the <TT>A</TT> subobject
of <TT>B</TT>.  But we can't, because it isn't allowed by
12.8 [class.copy] paragraph 34 bullet 3:</P>

<UL><LI><P>when a temporary class object that has not been bound
to a reference (12.2 [class.temporary]) would be copied/moved
to a class object with the same cv-unqualified type, the
copy/move operation can be omitted by constructing the temporary
object directly into the target of the omitted
copy/move</P></LI></UL>

<P>The part about not being bound to a reference was added for an
unrelated reason by <A HREF="
     cwg_defects.html#185">issue 185</A>.  If
that resolution were recast to require that the temporary object
is not accessed after the copy, rather than banning the reference
binding, this optimization could be applied.</P>

<P>The similar example using pass by value is also not one of the
allowed cases, which could be considered part of <A HREF="
     cwg_active.html#6">issue 6</A>.
</P>

<BR><BR><HR><A NAME="545"></A><H4>545.
  
User-defined conversions and built-in operator overload resolution
</H4><B>Section: </B>13.3.1.2&#160; [over.match.oper]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Clamage
 &#160;&#160;&#160;

 <B>Date: </B>31 October 2005<BR>




<P>Consider the following example:</P>

<PRE>
    class B1 {};
    typedef void (B1::*PB1) (); //<SPAN style="font-family:Times;font-style:italic"> memptr to </SPAN>B1

    class B2 {};
    typedef void (B2::*PB2) (); //<SPAN style="font-family:Times;font-style:italic"> memptr to </SPAN>B2

    class D1 : public B1, public B2 {};
    typedef void (D1::*PD) (); //<SPAN style="font-family:Times;font-style:italic"> memptr to </SPAN>D1

    struct S {
         operator PB1(); //<SPAN style="font-family:Times;font-style:italic"> can be converted to </SPAN>PD
    } s;
    struct T {
         operator PB2(); //<SPAN style="font-family:Times;font-style:italic"> can be converted to </SPAN>PD
    } t;

    void foo() {
         s == t; //<SPAN style="font-family:Times;font-style:italic"> Is this an error?</SPAN>
    }
</PRE>

<P>According to 13.6 [over.built] paragraph 16, there is an
<TT>operator==</TT> for <TT>PD</TT> (&#8220;For every pointer to
member type...&#8221;), so why wouldn't it be used for this
comparison?</P>

<P><U>Mike Miller</U>: The problem, as I understand it, is that
13.3.1.2 [over.match.oper] paragraph 3, bullet 3, sub-bullet 3
is broader than it was intended to be.  It says that candidate
built-in operators must &#8220;accept operand types to which the given
operand or operands can be converted according to 13.3.3.1 [over.best.ics].&#8221; 13.3.3.1.2 [over.ics.user]
describes user-defined conversions as having a second standard
conversion sequence, and there is nothing to restrict that second
standard conversion sequence.</P>

<P>My initial thought on addressing this would be to say that
user-defined conversion sequences whose second standard conversion
sequence contains a pointer conversion or a pointer-to-member
conversion are not considered when selecting built-in candidate
operator functions.  They would still be applicable after the hand-off
to Clause 5 (e.g., in bringing the operands to their common type,
5.10 [expr.eq], or composite pointer type, 5.9 [expr.rel]), just not in constructing the list of built-in
candidate operator functions.</P>

<P>I started to suggest restricting the second standard conversion
sequence to conversions having Promotion or Exact Match rank, but that
would exclude the Boolean conversions, which are needed
for <TT>!</TT>, <TT>&amp;&amp;</TT>, and <TT>||</TT>.  (It would have
also restricted the floating-integral conversions, though, which might
be a good idea.  They can't be used implicitly, I think, because there
would be an ambiguity among all the promoted integral types; however,
none of the compilers I tested even tried those conversions because
the errors I got were not ambiguities but things like &#8220;floating
point operands not allowed for <TT>%</TT>&#8221;.)</P>

<P><U>Bill Gibbons</U>: I recall seeing this problem before, though
possibly not in committee discussions.  As written this rule makes the
set of candidate functions dependent on what classes have been
defined, including classes not otherwise required to have been defined
in order for "==" to be meaningful.  For templates this implies that
the set is dependent on what templates have been instantiated,
e.g.</P>

<PRE>
  template&lt;class T&gt; class U : public T { };
  U&lt;B1&gt; u;  //<SPAN style="font-family:Times;font-style:italic"> changes the set of candidate functions to include</SPAN>
            //<SPAN style="font-family:Times;font-style:italic"> </SPAN>operator==(U&lt;B1&gt;,U&lt;B1&gt;)<SPAN style="font-family:Times;font-style:italic">?</SPAN>
</PRE>

<P>There may be other places where the existence of a class
definition, or worse, a template instantiation, changes the semantics
of an otherwise valid program (e.g. pointer conversions?) but it seems
like something to be avoided.</P>

<P>(See also <A HREF="
     cwg_active.html#954">issue 954</A>.)</P>

<BR><BR><HR><A NAME="1750"></A><H4>1750.
  
&#8220;Argument&#8221; vs &#8220;parameter&#8221;
</H4><B>Section: </B>13.3.1.4&#160; [over.match.copy]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-13<BR>


<P>The current wording of the second bullet of paragraph 1 of
13.3.1.4 [over.match.copy] contains the phrase,</P>

<BLOCKQUOTE>

When initializing a temporary to be bound to the first parameter of a
constructor that takes a reference to possibly cv-qualified <TT>T</TT> as
its first argument...

</BLOCKQUOTE>

<P>Presumably &#8220;argument&#8221; should be &#8220;parameter.&#8221;</P>

<BR><BR><HR><A NAME="1781"></A><H4>1781.
  
Converting from <TT>nullptr_t</TT> to <TT>bool</TT> in overload resolution
</H4><B>Section: </B>13.3.1.5&#160; [over.match.conv]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Hubert Tong
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-26<BR>


<P>According to 13.3.1.5 [over.match.conv] paragraph 1, when a class
type <TT>S</TT> is used as an initializer for an object of type <TT>T</TT>,
</P>

<BLOCKQUOTE>

The conversion functions of <TT>S</TT> and its base classes are
considered. Those non-explicit conversion functions that are not hidden
within <TT>S</TT> and yield type <TT>T</TT> or a type that can be converted
to type <TT>T</TT> via a standard conversion sequence
(13.3.3.1.1 [over.ics.scs]) are candidate functions.

</BLOCKQUOTE>

<P>Because conversion from <TT>std::nullptr_t</TT> to <TT>bool</TT>
is only permitted in direct-initialization (4.12 [conv.bool]),
it is not clear whether there is a standard conversion sequence from
<TT>std::nullptr_t</TT> to <TT>bool</TT>, considering that an
implicit conversion sequence is intended to model
copy-initialization.  Should 13.3.1.5 [over.match.conv] be
understood to refer only to conversions permitted in
copy-initialization, or should the form of the initialization be
considered?  For example,</P>

<PRE>
  struct SomeType {
    operator std::nullptr_t();
  };
  bool b{ SomeType() };    //<SPAN style="font-family:Times;font-style:italic"> Well-formed?</SPAN>
</PRE>

<P>Note also 13.3.3.2 [over.ics.rank] paragraph 4, which may bear
on the intent (or, alternatively, might describe a situation that
cannot arise):</P>

<BLOCKQUOTE>

A conversion that does not convert a pointer, a pointer to member, or
<TT>std::nullptr_t</TT> to <TT>bool</TT> is better than one that does.

</BLOCKQUOTE>

<BR><BR><HR><A NAME="1758"></A><H4>1758.
  
Explicit conversion in copy/move list initialization
</H4><B>Section: </B>13.3.1.7&#160; [over.match.list]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-21<BR>




<P>Consider the following example:</P>

<PRE>
  struct X { X(); };
  struct Y { explicit operator X(); } y;
  X x{y};
</PRE>

<P>This appears to be ill-formed, although the corresponding case with
parentheses is well-formed.  There seem to be two factors that prevent
this from being accepted:</P>

<P>First, the special provision allowing an explicit conversion function to be
used when initializing the parameter of a copy/move constructor is in
13.3.1.4 [over.match.copy], and this case takes us to
13.3.1.7 [over.match.list] instead.</P>

<P>Second, 13.3.3.1 [over.best.ics] paragraph 4 says that in this
case, because we are in 13.3.1.7 [over.match.list], and we have a single
argument, and we are calling a copy/move constructor, we are not allowed to
consider a user-defined conversion sequence for the argument.</P>

<P>Similarly, in an example like</P>

<PRE>
  struct A {
   A() {}
   A(const A &amp;) {}
  };
  struct B {
   operator A() { return A(); }
  } b;
  A a{b};
</PRE>

<P>the wording in 13.3.3.1 [over.best.ics] paragraph 4 with regard to
13.3.1.7 [over.match.list] prevents considering <TT>B</TT>'s conversion
function when initializing the first parameter of <TT>A</TT>'s copy
constructor, thereby making this code ill-formed.</P>

<BR><BR><HR><A NAME="418"></A><H4>418.
  
Imperfect wording on error on multiple default arguments on a called function
</H4><B>Section: </B>13.3.3&#160; [over.match.best]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Chris Bowler
 &#160;&#160;&#160;

 <B>Date: </B>27 May 2003<BR>




<P>According to
13.3.3 [over.match.best] paragraph 4, the following program
appears to be ill-formed:</P>
<PRE>
  void f(int, int=0);
  void f(int=0, int);

  void g() {
    f();
  }
</PRE>
<P>Though I do not expect this is the intent of this paragraph in the
standard.</P>

<P>13.3.3 [over.match.best] paragraph 4:</P>
<BLOCKQUOTE>
If the best viable function resolves to a function for which multiple
declarations were found, and if at least
two of these declarations or the declarations they refer to in the case of
using-declarations specify a
default argument that made the function viable, the program is ill-formed.
[Example:
<PRE>
namespace A {
  extern "C" void f(int = 5);
}
namespace B {
  extern "C" void f(int = 5);
}
using A::f;
using B::f;
void use() {
f(3); //OK, default argument was not used for viability
f(); //Error: found default argument twice
}
</PRE>
end example]</BLOCKQUOTE>

<BR><BR><HR><A NAME="1459"></A><H4>1459.
  
Reference-binding tiebreakers in overload resolution
</H4><B>Section: </B>13.3.3.2&#160; [over.ics.rank]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2012-02-07<BR>


<P>Both paragraph 3 and paragraph 4 of 13.3.3.2 [over.ics.rank] have
overload resolution tiebreakers for reference binding.  It might be
possible to merge those into a single treatment.</P>

<BR><BR><HR><A NAME="1789"></A><H4>1789.
  
Array reference vs array decay in overload resolution
</H4><B>Section: </B>13.3.3.2&#160; [over.ics.rank]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Faisal Vali
 &#160;&#160;&#160;

 <B>Date: </B>2013-10-01<BR>




<P>The current rules make an example like</P>

<PRE>
  template&lt;class T, size_t N&gt; void foo(T (&amp;)[N]);
  template&lt;class T&gt; void foo(T *t);

  int arr[3]{1, 2, 3};
  foo(arr);
</PRE>

<P>ambiguous, even though the first is an identity match and the
second requires an lvalue transformation.  Is this desirable?</P>

<BR><BR><HR><A NAME="1038"></A><H4>1038.
  
Overload resolution of <TT>&amp;x.static_func</TT>
</H4><B>Section: </B>13.4&#160; [over.over]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-02<BR>


<P>The Standard is not clear whether the following example is
well-formed or not:</P>

<PRE>
    struct S {
        static void f(int);
        static void f(double);
    };
    S s;
    void (*pf)(int) = &amp;s.f;
</PRE>

<P>According to 5.2.5 [expr.ref] paragraph 4 bullet 3,
you do function overload resolution to determine whether
<TT>x.f</TT> is a static or non-static member function.
5.3.1 [expr.unary.op] paragraph 6 says that you can only
take the address of an overloaded function in a context that
determines the overload to be chosen, and the initialization of a
function pointer is such a context (13.4 [over.over]
paragraph 1).  The problem is that 13.4 [over.over] is
phrased in terms of &#8220;an overloaded function name,&#8221;
and this is a member access expression, not a name.</P>

<P>There is variability among implementations as to whether this
example is accepted; some accept it as written, some only if the
<TT>&amp;</TT> is omitted, and some reject it in both forms.</P>

<P><B>Additional note (October, 2010):</B></P>

<P>A related question concerns an example like</P>

<PRE>
    struct S {
        static void g(int*) {}
        static void g(long) {}
    } s;

    void foo() {
        (&amp;s.g)(0L);
    }
</PRE>

<P>Because the address occurs in a call context and not in one of
the contexts mentioned in 13.4 [over.over] paragraph 1,
the call expression in <TT>foo</TT> is presumably ill-formed.
Contrast this with the similar example</P>

<PRE>
    void g1(int*) {}
    void g1(long) {}

    void foo1() {
        (&amp;g1)(0L);
    }
</PRE>

<P>This call presumably is well-formed because 13.3.1.1 [over.match.call] applies to &#8220;the address of a set of overloaded
functions.&#8221; (This was clearer in the wording prior to the
resolution of <A HREF="
     cwg_defects.html#704">issue 704</A>: &#8220;...in
this context using <TT>&amp;F</TT> behaves the same as using the
name <TT>F</TT> by itself.&#8221;) It's not clear that there's any
reason to treat these two cases differently.</P>

<P>This question also bears on the original question of this issue,
since the original wording of 13.3.1.1 [over.match.call] also
described the case of an ordinary member function call like
<TT>s.g(0L)</TT> as involving the &#8220;name&#8221; of the function,
even though the <I>postfix-expression</I> is a member access
expression and not a &#8220;name.&#8221; Perhaps the reference to
&#8220;name&#8221; in 13.4 [over.over] should be similarly
understood as applying to member access expressions?</P>



<BR><BR><HR><A NAME="1549"></A><H4>1549.
  
Overloaded comma operator with <TT>void</TT> operand
</H4><B>Section: </B>13.5.2&#160; [over.binary]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Nikolay Ivchenkov
 &#160;&#160;&#160;

 <B>Date: </B>2012-09-04<BR>




<P>Even though a function cannot take a parameter of type <TT>void</TT>,
the current rules for overload resolution require consideration of
overloaded operators when one operand has a user-defined or enumeration
type and the other has type <TT>void</TT>.  This can result in side
effects and possibly errors, for example:</P>

<PRE>
  template &lt;class T&gt; struct A {
    T t;
    typedef T type;
  };

  struct X {
    typedef A&lt;void&gt; type;
  };

  template &lt;class T&gt; void operator ,(typename T::type::type, T) {}

  int main() {
    X(), void(); //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
    void(), X(); //<SPAN style="font-family:Times;font-style:italic"> error: </SPAN>A&lt;void&gt;<SPAN style="font-family:Times;font-style:italic"> is instantiated with a field of</SPAN>
                 //<SPAN style="font-family:Times;font-style:italic"> type </SPAN>void
  }
</PRE>

<BR><BR><HR><A NAME="1620"></A><H4>1620.
  
User-defined literals and extended integer types
</H4><B>Section: </B>13.5.8&#160; [over.literal]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2013-02-12<BR>




<P>Although numeric literals can have extended integer types,
user-defined literal operators cannot have a parameter of an
extended integer type.  This seems like an oversight.</P>

<BR><BR><HR><A NAME="260"></A><H4>260.
  
User-defined conversions and built-in <TT>operator=</TT>
</H4><B>Section: </B>13.6&#160; [over.built]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Scott Douglas
 &#160;&#160;&#160;

 <B>Date: </B>4 Nov 2000<BR>


<P>According to the Standard (although not implemented this way
in most implementations), the following code exhibits non-intuitive
behavior:</P>

<PRE>
  struct T {
    operator short() const;
    operator int() const;
  };

  short s;

  void f(const T&amp; t) {
    s = t;  // surprisingly calls T::operator int() const
  }
</PRE>

<P>The reason for this choice is 13.6 [over.built]
paragraph 18:</P>

<BLOCKQUOTE>

<P>For every triple (<I>L</I>, <I>VQ</I>, <I>R</I>), where <I>L</I> is an
arithmetic type, <I>VQ</I> is either <TT>volatile</TT> or empty, and
<I>R</I> is a promoted arithmetic type, there exist candidate operator
functions of the form</P> 

<UL><I>VQ</I> <I>L</I><TT>&amp; operator=(</TT><I>VQ L</I><TT>&amp;,</TT> <I>R</I><TT>);</TT></UL>

</BLOCKQUOTE>

<P>Because <I>R</I> is a "promoted arithmetic type," the second argument
to the built-in assignment operator is <TT>int</TT>, causing the
unexpected choice of conversion function.</P>

<P><B>Suggested resolution:</B> Provide built-in assignment operators
for the unpromoted arithmetic types.</P>

<P>Related to the preceding, but not resolved by the suggested
resolution, is the following problem.  Given:</P>

<PRE>
    struct T {
	 operator int() const;
	 operator double() const;
    };
</PRE>

<P>I believe the standard requires the following assignment to be
ambiguous (even though I expect that would surprise the user):</P>

<PRE>
    double x;
    void f(const T&amp; t) { x = t; }
</PRE>

<P>The problem is that both of these built-in <TT>operator=()</TT>s exist
(13.6 [over.built] paragraph 18):</P>

<PRE>
    double&amp; operator=(double&amp;, int);
    double&amp; operator=(double&amp;, double);
</PRE>

<P>Both are an exact match on the first argument and a user conversion
on the second.  There is no rule that says one is a better match than
the other.</P>

<P>The compilers that I have tried (even in their strictest setting)
do not give a peep.  I think they are not following the standard.
They pick <TT>double&amp; operator=(double&amp;, double)</TT> and use
<TT>T::operator double() const</TT>.</P>

<P>I hesitate to suggest changes to overload resolution, but a
possible resolution might be to introduce a rule that, for built-in
<TT>operator=</TT> only, also considers the conversion sequence from
the second to the first type.  This would also resolve the earlier
question.</P>

<P>It would still leave <TT>x += t</TT> etc. ambiguous -- which might
be the desired behavior and is the current behavior of some
compilers.</P>

<P><B>Notes from the 04/01 meeting:</B></P>

<P>The difference between initialization and assignment is
disturbing.  On the other hand, promotion is ubiquitous in the
language, and this is the beginning of a very slippery slope (as
the second report above demonstrates).
</P>

<P><B>Additional note (August, 2010):</B></P>

<P>See <A HREF="
     cwg_closed.html#507">issue 507</A> for a similar example
involving comparison operators.</P>

<BR><BR><HR><A NAME="954"></A><H4>954.
  
Overload resolution of conversion operator templates with built-in types
</H4><B>Section: </B>13.6&#160; [over.built]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Clamage
 &#160;&#160;&#160;

 <B>Date: </B>19 August, 2009<BR>


<P>Consider the following example:</P>

<PRE>
    struct NullClass {
        template&lt;typename T&gt; operator T () { return 0 ; }
    };

    int main() {
        NullClass n;
        n==5;        // #1
        return 0;
    }
</PRE>

<P>The comparison at #1 is, according to the current Standard,
ambiguous.  According to 13.6 [over.built] paragraph 12, the
candidates for <TT>operator==(L, R)</TT> include functions &#8220;for
every pair of promoted arithmetic types,&#8221; so <TT>L</TT> could be
either <TT>int</TT> or <TT>long</TT>, and the conversion operator
template will provide an exact match for either.</P>

<P>Some implementations unambiguously choose the <TT>int</TT> candidate.
Perhaps the overload resolution rules could be tweaked to prefer
candidates in which <TT>L</TT> and <TT>R</TT> are the same type?</P>

<P>(See also <A HREF="
     cwg_active.html#545">issue 545</A>.)</P>

<BR><BR><HR><A NAME="110"></A><H4>110.
  
Can template functions and classes be declared in the same scope?
</H4><B>Section: </B>14&#160; [temp]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>28 Apr 1999<BR>




<P>According to 14 [temp]
 paragraph 5,</P>
<BLOCKQUOTE>

Except that a function template can be overloaded either by
(non-template) functions with the same name or by other function
templates with the same name
(14.8.3 [temp.over]
), a template name declared
in namespace scope or in class scope shall be unique in that scope.

</BLOCKQUOTE>
3.3.10 [basic.scope.hiding]
 paragraph 2 agrees
that only functions, not function templates, can hide a class name
declared in the same scope:
<BLOCKQUOTE>

A class name (9.1 [class.name]
) or
enumeration name (7.2 [dcl.enum]
) can be
hidden by the name of an object, function, or enumerator declared in
the same scope.

</BLOCKQUOTE>
However, 3.3 [basic.scope]
 paragraph 4
treats functions and template functions together in this regard:
<BLOCKQUOTE>

Given a set of declarations in a single declarative region, each of
which specifies the same unqualified name,

<UL>
<LI>they shall all refer to the same entity, or all refer to functions
and function templates; or</LI>

<LI>exactly one declaration shall declare a class name or enumeration
name that is not a typedef name and the other declarations shall all
refer to the same object or enumerator, or all refer to functions and
function templates; in this case the class name or enumeration name is
hidden</LI>

</UL>
</BLOCKQUOTE>

<P><B>John Spicer:</B> You should be able to take an existing program
and replace an existing function with a function template without
breaking unrelated parts of the program.

In addition, all of the compilers I tried allow this usage (EDG, Sun,
egcs, Watcom, Microsoft, Borland).

I would recommend that function templates be handled exactly like functions
for purposes of name hiding.</P>

<P><B>Martin O'Riordan:</B> I don't see any justification for extending
the purview of what is decidedly a hack, just for the sake of consistency.
In fact, I think we should go further and in the interest of consistency, we
should deprecate the hack, scheduling its eventual removal from the C++
language standard.</P>

<P>The hack is there to allow old C programs and especially the
'stat.h' file to compile with minimum effort (also several other Posix and X
headers).  People changing such older programs have ample opportunity to "do
it right".  Indeed, if you are adding templates to an existing program, you
should probably be placing your templates in a 'namespace', so the issue
disappears anyway.  The lookup rules should be able to provide the behaviour
you need without further hacking.</P>
<BR><BR><HR><A NAME="343"></A><H4>343.
  
Make <TT>template</TT> optional in contexts that require a type
</H4><B>Section: </B>14.2&#160; [temp.names]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>23 April 2002<BR>


<P>By analogy with <TT>typename</TT>, the keyword <TT>template</TT>
used to indicate that a dependent name will be a template name should
be optional in contexts where a type is required, e.g.,
base class lists.  We could also consider member and parameter
declarations.</P>

<P>This was suggested by <A HREF="
     cwg_active.html#314">issue 314</A>.</P>

<BR><BR><HR><A NAME="579"></A><H4>579.
  
What is a &#8220;nested&#8221; <TT>&gt;</TT> or <TT>&gt;&gt;</TT>?
</H4><B>Section: </B>14.2&#160; [temp.names]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>11 May 2006<BR>


<P>The Standard does not normatively define which <TT>&gt;</TT> and
<TT>&gt;&gt;</TT> tokens are to be taken as closing a
<I>template-argument-list</I>; instead, 14.2 [temp.names]
paragraph 3 uses the undefined and imprecise term
&#8220;non-nested:&#8221;</P>

<BLOCKQUOTE>

When parsing a <I>template-id</I>, the first non-nested <TT>&gt;</TT>
is taken as the end of the <I>template-argument-list</I> rather than a
greater-than operator.  Similarly, the first
non-nested <TT>&gt;&gt;</TT> is treated as two consecutive but
distinct <TT>&gt;</TT> tokens, the first of which is taken as the end
of the <I>template-argument-list</I> and completes the <I>template-id</I>.

</BLOCKQUOTE>

<P>The (non-normative) footnote clarifies that</P>

<BLOCKQUOTE>

A <TT>&gt;</TT> that encloses the <I>type-id</I> of a <TT>dynamic_cast</TT>, <TT>static_cast</TT>,
<TT>reinterpret_cast</TT> or <TT>const_cast</TT>, or which encloses the
<I>template-argument</I>s of a subsequent <I>template-id</I>, is
considered nested for the purpose of this description.

</BLOCKQUOTE>

<P>Aside from the questionable wording of this footnote (e.g., in what
sense does a single terminating character &#8220;enclose&#8221;
anything, and is a nested <I>template-id</I>
&#8220;subsequent?&#8221;) and the fact that it is non-normative, it
does not provide a complete definition of what &#8220;nesting&#8221;
is intended to mean.  For example, is the first <TT>&gt;</TT> in this
putative <I>template-id</I> &#8220;nested&#8221; or not?</P>

<PRE>
    X&lt;a ? b &gt; c : d&gt;
</PRE>

<BR><BR><HR><A NAME="1794"></A><H4>1794.
  
<TT>template</TT> keyword and alias templates
</H4><B>Section: </B>14.2&#160; [temp.names]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jonathan Caves
 &#160;&#160;&#160;

 <B>Date: </B>2013-10-04<BR>


<P>The current wording of 14.2 [temp.names] paragraph 5 is:</P>

<BLOCKQUOTE>

A name prefixed by the keyword template shall be a <I>template-id</I> or
the name shall refer to a class template.

</BLOCKQUOTE>

<P>Presumably this should also allow <TT>template</TT> before alias
templates.  For example,</P>

<PRE>
  template&lt;template&lt;typename&gt; class Template&gt;
  struct Internal {
          template&lt;typename Arg&gt;
          using Bind = Template&lt;Arg&gt;;
  };

  template&lt;template&lt;typename&gt; class Template, typename Arg&gt;
  using Instantiate = Template&lt;Arg&gt;;

  template&lt;template&lt;typename&gt; class Template, typename Argument&gt;
  using Bind = Instantiate&lt;Internal&lt;Template&gt;::template Bind, Argument&gt;;
</PRE>

<BR><BR><HR><A NAME="440"></A><H4>440.
  
Allow implicit pointer-to-member conversion on nontype template argument
</H4><B>Section: </B>14.3&#160; [temp.arg]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>David Abrahams
 &#160;&#160;&#160;

 <B>Date: </B>13 Nov 2003<BR>


<P>None of my compilers accept this, which surprised me a little.  Is
the base-to-derived member function conversion considered to be a
runtime-only thing?</P>
<PRE>
  template &lt;class D&gt;
  struct B
  {
      template &lt;class X&gt; void f(X) {}
      template &lt;class X, void (D::*)(X) = &amp;B&lt;D&gt;::f&lt;X&gt; &gt;
      struct row {};
  };
  struct D : B&lt;D&gt;
  {
      void g(int);
      row&lt;int,&amp;D::g&gt; r1;
      row&lt;char*&gt; r2;
  };
</PRE>
<P><U>John Spicer</U>:
This is not among the permitted conversions listed in 14.3.</P>

<P>I'm not sure there is a terribly good reason for that.  Some of the
template argument rules for external entities were made conservatively
because of concerns about issues of mangling template argument names.</P>

<P><U>David Abrahams</U>:
I'd really like to see that restriction loosened.  It is a serious
inconvenience because there appears to be no way to supply a usable
default in this case.  Zero would be an OK default if I could use the
function pointer's equality to zero as a compile-time switch to
choose an empty function implementation:</P>
<PRE>
  template &lt;bool x&gt; struct tag {};

  template &lt;class D&gt;
  struct B
  {
      template &lt;class X&gt; void f(X) {}

      template &lt;class X, void (D::*pmf)(X) = 0 &gt;
      struct row {
          void h() { h(tag&lt;(pmf == 0)&gt;(), pmf); }
          void h(tag&lt;1&gt;, ...) {}
          void h(tag&lt;0&gt;, void (D::*q)(X)) { /*something*/}
      };
  };

  struct D : B&lt;D&gt;
  {
      void g(int);
      row&lt;int,&amp;D::g&gt; r1;
      row&lt;char*&gt; r2;
  };
</PRE>

<P>But there appears to be no way to get that effect either.  The result
is that you end up doing something like:</P>
<PRE>
      template &lt;class X, void (D::*pmf)(X) = 0 &gt;
      struct row {
          void h() { if (pmf) /*something*/ }
      };
</PRE>

<P>which invariably makes compilers warn that you're switching on a
constant expression.</P>

<BR><BR><HR><A NAME="150"></A><H4>150.
  
Template template parameters and default arguments
</H4><B>Section: </B>14.3.3&#160; [temp.arg.template]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>3 Aug 1999<BR>



<P>[Picked up by evolution group at October 2002 meeting.]</P>



<P>How are default template arguments handled with respect to template
template parameters?  Two separate questions have been raised:</P>

<OL>
<LI>
Do default template arguments allow a template argument to match a
template parameter with fewer template parameters, and can the
template template parameter be specialized using the smaller number of
template arguments?  For example,

<PRE>
    template &lt;class T, class U = int&gt;
    class ARG { };

    template &lt;class X, template &lt;class Y&gt; class PARM&gt;
    void f(PARM&lt;X&gt;) { }    // specialization permitted?

    void g() {
        ARG&lt;int&gt; x;        // actually ARG&lt;int, int&gt;
        f(x);              // does ARG (2 parms, 1 with default)
                           // match PARM (1 parm)?
</PRE>

Template template parameters are deducible
(14.8.2.5 [temp.deduct.type]
 paragraph 9),
but 14.3.3 [temp.arg.template]
 does not
specify how matching is done.

<P><U>Jack Rouse</U>:
I implemented template template parameters assuming template signature
matching is analogous to function type matching.  This seems like the
minimum reasonable implementation.  The code in the example would not
be accepted by this compiler.  However, template default arguments are
compile time entities so it seems reasonable to relax the matching
rules to allow cases like the one in the example.  But I would
consider this to be an extension to the language.</P>

<P><U>Herb Sutter</U>:
An open issue in the LWG is that the standard
doesn't explicitly permit or forbid implementations' adding additional
<I>template-parameter</I>s
to those specified by the standard, and the LWG may be
leaning toward explicitly permitting this. 
[Under this interpretation,]
if the standard is ever modified to allow additional
<I>template-parameter</I>s,
then writing "a template that takes a standard library template as a
template template parameter" won't be just ugly because you have to mention
the defaulted parameters; it would not be (portably) possible at all except
possibly by defining entire families of overloaded templates to account for
all the possible numbers of parameters
<TT>vector&lt;&gt;</TT> (or anything else) might
actually have. That seems unfortunate.</P></LI>

<LI>
Are default arguments permitted in the template parameter list of a
template template parameter?  For example,

<PRE>
    template &lt;template &lt;class T, class U = int&gt; class PARM&gt;
    class C {
        PARM&lt;int&gt; pi;
    };
</PRE>

<P><U>Jack Rouse</U>:
I decided they could not in the compiler I support.  This continues
the analogy with function type matching.  Also, I did not see a strong
need to allow default arguments in this context.</P>

<P>A class template used as a template template argument can have default
template arguments from its declarations.  How are the two sources of
default arguments to be reconciled?  The default arguments from the
template template formal could override.  But it could be cofusing if
a <I>template-id</I> using the argument template, <TT>ARG&lt;int&gt;</TT>, behaves
differently from a <I>template-id</I> using the template formal name,
<TT>FORMAL&lt;int&gt;</TT>.</P></LI>

</OL>

<P><B>Rationale (10/99):</B> Template template parameters are intended
to be handled analogously to function function parameters.  Thus the
number of parameters in a template template argument must match the
number of parameters in a template template parameter, regardless of
whether any of those paramaters have default arguments or not.  Default
arguments are allowed for the parameters of a template template
parameter, and those default arguments alone will be considered in
a specialization of the template template parameter within a template
definition; any default arguments for the parameters of a template
template argument are ignored.</P>

<P><B>Note (Mark Mitchell, February, 2006):</B></P>

<P>Perhaps it is already obvious to all, but it seems worth noting that
this extension would change the meaning of conforming programs:</P>

<PRE>
    struct Dense { static const unsigned int dim = 1; };

    template &lt;template &lt;typename&gt; class View,
              typename Block&gt;
    void operator+(float, View&lt;Block&gt; const&amp;);

    template &lt;typename Block,
              unsigned int Dim = Block::dim&gt;
    struct Lvalue_proxy { operator float() const; };

    void test_1d (void) {
        Lvalue_proxy&lt;Dense&gt; p;
        float b;
        b + p;
    }
</PRE>

<P>If <TT>Lvalue_proxy</TT> is allowed to bind to <TT>View</TT>, then the
template <TT>operator+</TT> will be used to perform addition; otherwise,
<TT>Lvalue_proxy</TT>'s implicit conversion to float, followed by the
built-in addition on floats will be used.</P>

<P><B>Note (March, 2008):</B></P>

<P>The Evolution Working Group has accepted the intent of this issue
and referred it to CWG for action (not for C++0x).  See paper
J16/07-0033 = WG21 N2173.</P>

<P><B>Notes from the June, 2008 meeting:</B></P>

<P>The CWG decided to take no action on this issue until an interested
party produces a paper with analysis and a proposal.</P>
<BR><BR><HR><A NAME="708"></A><H4>708.
  
Partial specialization of member templates of class templates
</H4><B>Section: </B>14.5.5&#160; [temp.class.spec]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>James Widman
 &#160;&#160;&#160;

 <B>Date: </B>8 Aug, 2008<BR>




<P>The Standard does not appear to specify clearly the effect of a
partial specialization of a member template of a class template.
For example:</P>

<PRE>
    template&lt;class T&gt; struct B {
         template&lt;class U&gt; struct A { // #1
             void h() {}
         };
         template&lt;class U&gt; struct A&lt;U*&gt; {  // #2
             void f() {}
         };
    };

    template&lt;&gt; template&lt;class U&gt; struct B&lt;int&gt;::A { // #3
         void g() {}
    };

    void q(B&lt;int&gt;::A&lt;char*&gt;&amp; p) {
         p.f();  // #4
    }
</PRE>

<P>The explicit specialization at #3 replaces the primary member
template #1 of <TT>B&lt;int&gt;</TT>; however, it is not clear
whether the partial specialization #2 should be considered to
apply to the explicitly-specialized member template of
<TT>A&lt;int&gt;</TT> (thus allowing the call to <TT>p.f()</TT>
at #4) or whether the partial specialization will be used only
for specializations of <TT>B</TT> that are implicitly
instantiated (meaning that #4 could call <TT>p.g()</TT> but not
<TT>p.f()</TT>).</P>

<BR><BR><HR><A NAME="1711"></A><H4>1711.
  
Missing specification of variable template partial specializations
</H4><B>Section: </B>14.5.5&#160; [temp.class.spec]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-07-08<BR>




<P>It appears that partial specializations of variable templates are
intended to be supported, as 14.3.3 [temp.arg.template] paragraph 2
says,</P>

<BLOCKQUOTE>

Any partial specializations (14.5.5 [temp.class.spec]) associated with
the primary class template or primary variable template are considered when
a specialization based on the template <I>template-parameter</I> is
instantiated.

</BLOCKQUOTE>

<P>However, there is no explicit specification for how they are to be
handled, and the wording in 14.5.5 [temp.class.spec] and its
subsections explicitly applies only to partial specializations of
class templates.</P>

<BR><BR><HR><A NAME="1754"></A><H4>1754.
  
Declaration of partial specialization of static data member template
</H4><B>Section: </B>14.5.5&#160; [temp.class.spec]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-19<BR>




<P>There does not appear to be a way to declare (not define) a partial
specialization of a static data member template outside outside its
class.  The rule for explicit specializations (14.7.3 [temp.expl.spec]
paragraph 13) is that the presence or absence of an initializer determines
whether the explicit specialization is a definition or not.  Applying
this rule to the partial specialization case, however, would conflict with
being able to provide an initializer on the declaration within the class.</P>

<P>Do we need to support declaring partial specializations of static
data member templates outside their class?</P>

<BR><BR><HR><A NAME="1755"></A><H4>1755.
  
Out-of-class partial specializations of member templates
</H4><B>Section: </B>14.5.5.3&#160; [temp.class.spec.mfunc]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-19<BR>




<P>According to 14.5.5.3 [temp.class.spec.mfunc] paragraph 2,</P>

<BLOCKQUOTE>

If a member template of a class template is partially specialized, the
member template partial specializations are member templates of the
enclosing class template; if the enclosing class template is instantiated
(14.7.1 [temp.inst], 14.7.2 [temp.explicit]), a declaration
for every member template partial specialization is also instantiated as
part of creating the members of the class template specialization.

</BLOCKQUOTE>

<P>Does this imply that only partial specializations of member templates
that are declared before the enclosing class is instantiated are
considered?  For example, in</P>

<PRE>
  template&lt;typename A&gt; struct X { template&lt;typename B&gt; struct Y; };
  template struct X&lt;int&gt;;
  template&lt;typename A&gt; template&lt;typename B&gt; struct X&lt;A&gt;::Y&lt;B*&gt; { int n; };
  int k = X&lt;int&gt;::Y&lt;int*&gt;().n;
</PRE>

<P>is the last line valid?  There is implementation variance on this
point.  Similarly, for an example like</P>

<PRE>
  template&lt;typename A&gt; struct Outer {
   template&lt;typename B, typename C&gt; struct Inner;
  };
  Outer&lt;int&gt; outer;
  template&lt;typename A&gt; template&lt;typename B&gt;
    struct Outer&lt;A&gt;::Inner&lt;typename A::error, B&gt; {};
</PRE>

<P>at what point, if at all, is the declaration of the partial
specialization instantiated?  Again, there is implementation variance in
the treatment of this example.</P>

<BR><BR><HR><A NAME="310"></A><H4>310.
  
Can function templates differing only in parameter cv-qualifiers be overloaded?
</H4><B>Section: </B>14.5.6.1&#160; [temp.over.link]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Andrei Iltchenko
 &#160;&#160;&#160;

 <B>Date: </B>29 Aug 2001<BR>


<P>I get the following error diagnostic [from the EDG front end]:
<PRE>
line 8: error: function template "example&lt;T&gt;::foo&lt;R,A&gt;(A)" has
          already been declared
     R  foo(const A);
        ^
</PRE>
when compiling this piece of code:
<PRE>
struct  example  {
   template&lt;class R, class A&gt;   // 1-st member template
   R  foo(A);
   template&lt;class R, class A&gt;   // 2-nd member template
   const R  foo(A&amp;);
   template&lt;class R, class A&gt;   // 3-d  member template
   R  foo(const A);
};

/*template&lt;&gt; template&lt;&gt;
int  example&lt;char&gt;::foo(int&amp;);*/


int  main()
{
   int  (example&lt;char&gt;::* pf)(int&amp;) =
      &amp;example&lt;char&gt;::foo;
}
</PRE>
</P>

<P>The implementation complains that
<PRE>
   template&lt;class R, class A&gt;   // 1-st member template
   R  foo(A);
   template&lt;class R, class A&gt;   // 3-d  member template
   R  foo(const A);
</PRE>
cannot be overloaded and I don't see any reason for it
since it is function template specializations that are
treated like ordinary non-template functions, meaning
that the transformation of a
parameter-declaration-clause into the corresponding
parameter-type-list is applied to specializations
(when determining its type) and not to function
templates.</P>

<P>What makes me think so is the contents of 14.5.6.1 [temp.over.link]
and the following sentence from 14.8.2.1 [temp.deduct.call] "If P is a
cv-qualified type, the top level cv-qualifiers of P
are ignored for type deduction". If the transformation
was to be applied to function templates, then there
would be no reason for having that sentence in
14.8.2.1 [temp.deduct.call].</P>

<P>14.8.2.2 [temp.deduct.funcaddr], which my example is
based upon, says nothing
about ignoring the top level cv-qualifiers of the
function parameters of the function template whose
address is being taken.</P>

<P>As a result, I expect that template argument deduction
will fail for the 2-nd and 3-d member templates and
the 1-st one will be used for the instantiation of the
specialization.</P>

<BR><BR><HR><A NAME="1644"></A><H4>1644.
  
Equivalent <I>exception-specification</I>s in function template declarations
</H4><B>Section: </B>14.5.6.1&#160; [temp.over.link]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-03-17<BR>




<P>Although 15.4 [except.spec] paragraph 3 says,</P>

<BLOCKQUOTE>

<P>Two <I>exception-specification</I>s are <I>compatible</I> if:</P>

<UL><LI><P>...</P></LI>

<LI><P>both have the
form <TT>noexcept(</TT><I>constant-expression</I><TT>)</TT>
and the <I>constant-expression</I>s are equivalent,
or</P></LI>

<LI><P>...</P></LI>

</UL>

</BLOCKQUOTE>

<P>it is not clear whether &#8220;equivalent&#8221; in this context
should be taken as a reference to the definition of
<I>equivalent</I> given in 14.5.6.1 [temp.over.link] paragraph
5:</P>

<BLOCKQUOTE>

Two expressions involving template parameters are considered
<I>equivalent</I> if two function definitions containing the
expressions would satisfy the one definition rule
(3.2 [basic.def.odr]), except that the tokens used to
name the template parameters may differ as long as a token
used to name a template parameter in one expression is
replaced by another token that names the same template
parameter in the other expression.

</BLOCKQUOTE>

<P>since the context there is expressions that appear in function
template parameters and return types.</P>

<P>There is implementation variance on this question.</P>

<BR><BR><HR><A NAME="402"></A><H4>402.
  
More on partial ordering of function templates
</H4><B>Section: </B>14.5.6.2&#160; [temp.func.order]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Nathan Sidwell
 &#160;&#160;&#160;

 <B>Date: </B>7 Apr 2003<BR>




<P>This was split off from <A HREF="
     cwg_defects.html#214">issue 214</A> at
the April 2003 meeting.</P>

<P><U>Nathan Sidwell</U>:
John Spicer's proposed resolution does not make the following
well-formed.</P>
<PRE>
  template &lt;typename T&gt; int Foo (T const *) {return 1;} //#1
  template &lt;unsigned I&gt; int Foo (char const (&amp;)[I]) {return 2;} //#2

  int main ()
  {
    return Foo ("a") != 2;
  }
</PRE>
<P>Both #1 and #2 can deduce the "a" argument, #1 deduces T as char and
#2 deduces I as 2. However, neither is more specialized because the
proposed rules do not have any array to pointer decay.</P>

<P>#1 is only deduceable because of the rules in
14.8.2.1 [temp.deduct.call] paragraph 2 that
decay array and function type arguments when the template parameter is
not a reference. Given that such behaviour happens in deduction, I believe
there should be equivalent behaviour during partial ordering. #2 should be
resolved as more specialized as #1. The following alteration to the
proposed resolution of DR214 will do that.</P>

<P>Insert before,</P>
<UL>
<LI>If A is a cv-qualified type, A is replaced by the
         cv-unqualified version of A.</LI>
</UL>
<P>the following</P>
<UL>
<LI>If P was not originally a reference type,
<UL>
<LI>If A is an array type, A is replaced by the pointer type produced
            by the array to pointer conversion</LI>
<LI>If A is a function type, A is replaced by the pointer type
            produced by the function to pointer conversion</LI>
</UL>
</LI>
</UL>

<P>For the example above, this change results in deducing 'T const *' against
'char const *' in one direction (which succeeds), and 'char [I]'
against 'T const *' in the other (which fails).</P>

<P><U>John Spicer</U>:
I don't consider this a shortcoming of my proposed wording, as I don't
think this is part of the current rules.  In other words, the
resolution of 214 might make it clearer how this case is handled
(i.e., clearer that it is not allowed), but I don't believe it
represents a change in the language.</P>

<P>I'm not necessarily opposed to such a change, but I think it should be
reviewed by the core group as a related change and not a defect in the
proposed resolution to 214.</P>

<P><B>Notes from the October 2003 meeting:</B></P>

<P>There was some sentiment that it would be desirable to have
this case ordered, but we don't think it's worth spending the
time to work on it now.  If we look at some larger partial
ordering changes at some point, we will consider this again.</P>

<BR><BR><HR><A NAME="1157"></A><H4>1157.
  
Partial ordering of function templates is still underspecified
</H4><B>Section: </B>14.5.6.2&#160; [temp.func.order]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>CA
 &#160;&#160;&#160;

 <B>Date: </B>2010-08-03<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3296.html#CA7">N3092 comment
  CA&#160;7<BR></A>

<P>14.5.6.2 [temp.func.order] paragraph 3 says,</P>

<BLOCKQUOTE>

To produce the transformed template, for each type,
non-type, or template template parameter (including template
parameter packs (14.5.3 [temp.variadic]) thereof)
synthesize a unique type, value, or class template
respectively and substitute it for each occurrence of that
parameter in the function type of the template.

</BLOCKQUOTE>

<P>The characteristics of the synthesized entities and how they
are determined is not specified.  For example, members of a dependent
type referred to in non-deduced contexts are not specified to exist,
even though the transformed function type would be invalid in their
absence.</P>

<P>Example 1:</P>

<PRE>
  template&lt;typename T, typename U&gt; struct A;
  template&lt;typename T&gt; void foo(A&lt;T, typename T::u&gt; *) { } //<SPAN style="font-family:Times;font-style:italic"> #1</SPAN>
    //<SPAN style="font-family:Times;font-style:italic"> synthetic </SPAN>T1<SPAN style="font-family:Times;font-style:italic"> has member </SPAN>T1::u
  template &lt;typename T&gt; void foo(A&lt;T, typename T::u::v&gt; *) { } //<SPAN style="font-family:Times;font-style:italic"> #2</SPAN>
    //<SPAN style="font-family:Times;font-style:italic"> synthetic </SPAN>T2<SPAN style="font-family:Times;font-style:italic"> has member </SPAN>T2::u<SPAN style="font-family:Times;font-style:italic"> and member </SPAN>T2::u::v
    //<SPAN style="font-family:Times;font-style:italic"> </SPAN>T<SPAN style="font-family:Times;font-style:italic"> in #1 deduces to synthetic </SPAN>T2<SPAN style="font-family:Times;font-style:italic"> in partial ordering;</SPAN>
    //<SPAN style="font-family:Times;font-style:italic"> deduced </SPAN>A<SPAN style="font-family:Times;font-style:italic"> for the parameter is </SPAN>A&lt;T2, T2::u&gt; *<SPAN style="font-family:Times;font-style:italic"> --this is not necessarily compatible</SPAN>
    //<SPAN style="font-family:Times;font-style:italic"> with </SPAN>A&lt;T2, T2::u::v&gt; *<SPAN style="font-family:Times;font-style:italic"> and it does not need to be. See Note 1. The effect is that</SPAN>
    //<SPAN style="font-family:Times;font-style:italic"> (in the call below) the compatibility of </SPAN>B::u<SPAN style="font-family:Times;font-style:italic"> and </SPAN>B::u::v<SPAN style="font-family:Times;font-style:italic"> is respected.</SPAN>
    //<SPAN style="font-family:Times;font-style:italic"> </SPAN>T<SPAN style="font-family:Times;font-style:italic"> in #2 cannot be successfully deduced in partial ordering from </SPAN>A&lt;T1, T1::u&gt; *;
    //<SPAN style="font-family:Times;font-style:italic"> invalid type </SPAN>T1::u::v<SPAN style="font-family:Times;font-style:italic"> will be formed when </SPAN>T1<SPAN style="font-family:Times;font-style:italic"> is substituted into non-deduced contexts.</SPAN>
  struct B {
    struct u { typedef u v; };
  };
  int main() {
    foo((A&lt;B, B::u&gt; *)0); //<SPAN style="font-family:Times;font-style:italic"> calls #2</SPAN>
  }
</PRE>

<P>Note 1: Template argument deduction is an attempt to
match a <TT>P</TT> and a deduced <TT>A</TT>; however,
template argument deduction is not specified to fail if the
<TT>P</TT> and the deduced <TT>A</TT> are incompatible. This
may occur in the presence of non-deduced contexts.
Notwithstanding the parenthetical statement in 14.8.2.4 [temp.deduct.partial] paragraph 9, template argument deduction
may succeed in determining a template argument for every
template parameter while producing a deduced <TT>A</TT> that
is not compatible with the corresponding <TT>P</TT>.</P>

<P>Example 2:</P>

<PRE>
  template &lt;typename T, typename U, typename V&gt; struct A;
  template &lt;typename T&gt;
    void foo(A&lt;T, struct T::u, struct T::u::u&gt; *); //<SPAN style="font-family:Times;font-style:italic"> #2.1</SPAN>
      //<SPAN style="font-family:Times;font-style:italic"> synthetic </SPAN>T1<SPAN style="font-family:Times;font-style:italic"> has member non-union class </SPAN>T1::u
  template &lt;typename T, typename U&gt;
    void foo(A&lt;T, U , U&gt; *); //<SPAN style="font-family:Times;font-style:italic"> #2.2</SPAN>
      //<SPAN style="font-family:Times;font-style:italic"> synthetic </SPAN>T2<SPAN style="font-family:Times;font-style:italic"> and </SPAN>U2<SPAN style="font-family:Times;font-style:italic"> has no required properties</SPAN>
      //<SPAN style="font-family:Times;font-style:italic"> </SPAN>T<SPAN style="font-family:Times;font-style:italic"> in #2.1 cannot be deduced in partial ordering from </SPAN>A&lt;T2, U2, U2&gt; *;
      //<SPAN style="font-family:Times;font-style:italic"> invalid types </SPAN>T2::u<SPAN style="font-family:Times;font-style:italic"> and </SPAN>T2::u::u<SPAN style="font-family:Times;font-style:italic"> will be formed when </SPAN>T2<SPAN style="font-family:Times;font-style:italic"> is substituted in nondeduced contexts.</SPAN>
      //<SPAN style="font-family:Times;font-style:italic"> </SPAN>T<SPAN style="font-family:Times;font-style:italic"> and </SPAN>U<SPAN style="font-family:Times;font-style:italic"> in #2.2 deduces to, respectively, </SPAN>T1<SPAN style="font-family:Times;font-style:italic"> and </SPAN>T1::u<SPAN style="font-family:Times;font-style:italic"> from </SPAN>A&lt;T1, T1::u, struct
T1::u::u&gt; *<SPAN style="font-family:Times;font-style:italic"> unless</SPAN>
      //<SPAN style="font-family:Times;font-style:italic"> </SPAN>struct T1::u::u<SPAN style="font-family:Times;font-style:italic"> does not refer to the injected-class-name of the class </SPAN>T1::u<SPAN style="font-family:Times;font-style:italic"> (if that is possible).</SPAN>
  struct B {
    struct u { };
  };
  int main() {
    foo((A&lt;B, B::u, struct B::u::u&gt; *)0); //<SPAN style="font-family:Times;font-style:italic"> calls #2.1</SPAN>
  }
</PRE>

<P>It is, however, unclear to what extent an implementation
will have to go to determine these minimal properties.</P>

<BR><BR><HR><A NAME="1257"></A><H4>1257.
  
Instantiation via non-dependent references in uninstantiated templates
</H4><B>Section: </B>14.6&#160; [temp.res]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2011-03-09<BR>




<P>The Standard does not appear to specify whether a non-dependent
reference to a template specialization in a template definition that is
never instantiated causes the implicit instantiation of the referenced
specialization.</P>

<BR><BR><HR><A NAME="1785"></A><H4>1785.
  
Conflicting diagnostic requirements for template definitions
</H4><B>Section: </B>14.6&#160; [temp.res]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>CWG
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-28<BR>


<P>According to 14.6 [temp.res] paragraph 8,</P>

<BLOCKQUOTE>

No diagnostic shall be issued for a template for which a valid
specialization can be generated.

</BLOCKQUOTE>

<P>One sentence later, it says,</P>

<BLOCKQUOTE>

If every valid specialization of a variadic template requires an empty
template parameter pack, the template is ill-formed, no diagnostic
required.

</BLOCKQUOTE>

<P>This appears to be a contradiction: in the latter case, there is
postulated to exist a &#8220;valid&#8221; specialization (with an empty
pack expansion), for which a diagnostic might or might not be issued.  The
first quoted sentence, however, forbids issuing a diagnostic for a template
that has at least one valid specialization.</P>

<BR><BR><HR><A NAME="186"></A><H4>186.
  
Name hiding and template <I>template-parameter</I>s
</H4><B>Section: </B>14.6.1&#160; [temp.local]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>11 Nov 1999<BR>





<P>The standard prohibits a class template from having the same name as
one of its template parameters
(14.6.1 [temp.local]
 paragraph 4).  This prohibits</P>

<PRE>
    template &lt;class X&gt; class X;
</PRE>

for the reason that the template name would hide the parameter, and
such hiding is in general prohibited.

<P>Presumably, we should also prohibit</P>

<PRE>
    template &lt;template &lt;class T&gt; class T&gt; struct A;
</PRE>

for the same reason.
<BR><BR><HR><A NAME="459"></A><H4>459.
  
Hiding of template parameters by base class members
</H4><B>Section: </B>14.6.1&#160; [temp.local]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2 Feb 2004<BR>


<P>Currently, member of nondependent base classes hide
references to template parameters in the definition
of a derived class template.</P>

<P>Consider the following example:</P>
<PRE>
   class B {
      typedef void *It;    // (1)
      // ...
    };

    class M: B {};

    template&lt;typename&gt; X {};

    template&lt;typename It&gt; struct S   // (2)
        : M, X&lt;It&gt; {   // (3)
      S(It, It);   // (4)
      // ...
    };
</PRE>
<P>As the C++ language currently stands, the name "It"
in line (3) refers to the template parameter declared
in line (2), but the name "It" in line (4) refers to
the typedef in the private base class (declared in
line (1)).</P>

<P>This situation is both unintuitive and a hindrance
to sound software engineering.  (See also the Usenet
discussion at http://tinyurl.com/32q8d .)  Among
other things, it implies that the private section
of a base class may change the meaning of the derived
class, and (unlike other cases where such things
happen) there is no way for the writer of the derived
class to defend the code against such intrusion (e.g.,
by using a qualified name).</P>

<P>Changing this can break code that is valid today.
However, such code would have to:
<OL>
<LI>
name a template parameter and not use it
         after the opening brace, and
</LI>
<LI>
use that same name to access a base-class
         name within the braces.
</LI>
</OL>
I personally have no qualms breaking such a program.</P>

<P>It has been suggested to make situations like these
ill-formed.  That solution is unattractive however
because it still leaves the writer of a derived class
template without defense against accidental name
conflicts with base members.  (Although at least the
problem would be guaranteed to be caught at compile
time.)  Instead, since just about everyone's intuition
agrees, I would like to see the rules changed to
make class template parameters hide members of the
same name in a base class.</P>

<P>See also <A HREF="
     cwg_defects.html#458">issue 458</A>.</P>

<P><B>Notes from the March 2004 meeting:</B></P>

<P>We have some sympathy for a change, but the current rules fall
straightforwardly out of the lookup rules, so they're not
&#8220;wrong.&#8221; Making private members invisible also would solve
this problem.  We'd be willing to look at a paper proposing that.</P>

<P><B>Additional discussion (April, 2005):</B></P>



<P><U>John Spicer</U>: Base class members are more-or-less treated as
members of the class, [so] it is only natural that the base [member]
would hide the template parameter.</P>

<P><U>Daveed Vandevoorde</U>: Are base class members really
&#8220;more or less&#8221; members of the class from a lookup
perspective?  After all, derived class members can hide base class
members of the same name.  So there is some pretty definite
boundary between those two sets of names.  IMO, the template
parameters should either sit between those two sets, or they
should (for lookup purposes) be treated as members of the class
they parameterize (I cannot think of a practical difference
between those two formulations).</P>

<P><U>John Spicer</U>: How is [hiding template parameters]
different from the fact that namespace members can be hidden
by private parts of a base class?  The addition of <TT>int C</TT>
to <TT>N::A</TT> breaks the code in namespace <TT>M</TT> in this
example:</P>

<PRE>
    namespace N {
       class A {
    private:
         int C;
       };
    }

    namespace M {
       typedef int C;
       class B : public N::A {
         void f() {
             C c;
         }
       };
    }
</PRE>

<P><U>Daveed Vandevoorde</U>: C++ has a mechanism in place to handle
such situations: qualified names.  There is no such mechanism in place
for template parameters.</P>

<P><U>Nathan Myers</U>: What I see as obviously incorrect ... is
simply that a name defined right where I can see it, and directly
attached to the textual scope of <TT>B</TT>'s class body, is ignored
in favor of something found in some other file.  I don't care that
<TT>C1</TT> is defined in <TT>A</TT>, I have a <TT>C1</TT> right
here that I have chosen to use.  If I want <TT>A::C1</TT>, I can
say so.</P>

<P>I doubt you'll find any regular C++ coder who doesn't find the
standard behavior bizarre.  If the meaning of any code is changed
by fixing this behavior, the overwhelming majority of cases will
be mysterious bugs magically fixed.</P>

<P><U>John Spicer</U>: I have not heard complaints that this is
actually a cause of problems in real user code.  Where is the
evidence that the status quo is actually causing problems?</P>

<P>In this example, the <TT>T2</TT> that is found is the one from
the base class.  I would argue that this is natural because base
class members are found as part of the lookup in class <TT>B</TT>:</P>

<PRE>
    struct A {
             typedef int T2;
    };
    template &lt;class T2&gt; struct B : public A {
             typedef int T1;
             T1 t1;
             T2 t2;
    };
</PRE>

<P>This rule that base class members hide template parameters was
formalized about a dozen years ago because it fell out of the
principle that base class members should be found at the same
stage of lookup as derived class members, and that to do otherwise
would be surprising.</P>

<P><U>Gabriel Dos Reis</U>: The bottom line is that:</P>

<OL>

<LI>the proposed change is a <B>silent</B> change of meaning;</LI>

<LI>the proposed change does not make the language any more regular;
the current behavior is consistent with everything else, however
&#8220;surprising&#8221; that might be;</LI>

<LI>the proposed change does have its own downsides.</LI>

</OL>

<P>Unless presented with real major programming problems the current
rules exhibit, I do not think the simple rule &#8220;scopes
nest&#8221; needs a change that silently mutates program meaning.</P>

<P><U>Mike Miller</U>: The rationale for the current specification is
really very simple:</P>

<OL>

<LI>&#8220;Unless redeclared in the derived class, members of a base
class are also considered to be members of the derived class.&#8221;
(10 [class.derived] paragraph 2)</LI>

<LI>In class scope, members hide nonmembers.</LI>

</OL>

<P>That's it.  Because template parameters are not members, they
are hidden by member names (whether inherited or not).  I don't find
that &#8220;bizarre,&#8221; or even particularly surprising.</P>

<P>I believe these rules are straightforward and consistent, so I
would be opposed to changing them.  However, I am not unsympathetic
toward Daveed's concern about name hijacking from base classes.  How
about a rule that would make a program ill-formed if a direct or
inherited member hides a template parameter?</P>

<P>Unless this problem is a lot more prevalent than I've heard so
far, I would not want to change the lookup rules; making this kind of
collision a diagnosable error, however, would prevent hijacking
without changing the lookup rules.</P>

<P><U>Erwin Unruh</U>: I have a different approach that is consistent
and changes the interpretation of the questionable code.  At present
lookup is done in this sequence:</P>

<UL>
block scope<BR>
derived class scope<BR>
base class scope<BR>
template parameters<BR>
namespace scope
</UL>

<P>If we change this order to</P>

<UL>
template parameters<BR>
block scope<BR>
derived class scope<BR>
base class scope<BR>
namespace scope<BR>
</UL>

<P>it is still consistent in that no lookup is placed between the base
class and the derived class.  However, it introduces another
inconsistency: now scopes do not nest the same way as curly braces
nest &#8212; but base classes are already inconsistent this way.</P>

<P><U>Nathan Myers</U>: This looks entirely satisfactory.  If even this
seems like too big a change, it would suffice to say that finding a
different name by this search order makes the program ill-formed.
Of course, a compiler might issue only a portability warning in that
case and use the name found Erwin's way, anyhow.</P>

<P><U>Gabriel Dos Reis</U>: It is a simple fact, even without
templates, that a writer of a derived class cannot protect himself
against declaration changes in the base class.</P>

<P><U>Richard Corden</U>: If a change is to be made, then making it
ill-formed is better than just changing the lookup rules.</P>

<PRE>
    struct B
    {
      typedef int T;
      virtual void bar (T const &amp; );
    };

    template &lt;typename T&gt;
    struct D : public B
    {
      virtual void bar (T const &amp; );
    };

    template class D&lt;float&gt;;
</PRE>

<P>I think changing the semantics of the above code silently would
result in very difficult-to-find problems.</P>

<P><U>Mike Miller</U>: Another case that may need to be considered in
deciding on Erwin's suggestion or the &#8220;ill-formed&#8221;
alternative is the treatment of <TT>friend</TT> declarations
described in 3.4.1 [basic.lookup.unqual] paragraph 10:</P>

<PRE>
    struct A {
        typedef int T;
        void f(T);
    };
    template&lt;typename T&gt; struct B {
        friend void A::f(T);  //<SPAN style="font-family:Times;font-style:italic"> Currently </SPAN>T<SPAN style="font-family:Times;font-style:italic"> is </SPAN>A::T
    };
</PRE>

<P><B>Notes from the October, 2005 meeting:</B></P>

<P>The CWG decided not to consider a change to the existing rules at
this time without a paper exploring the issue in more detail.</P>
<BR><BR><HR><A NAME="1619"></A><H4>1619.
  
Definition of current instantiation
</H4><B>Section: </B>14.6.2.1&#160; [temp.dep.type]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2013-02-04<BR>




<P>The definition of the current instantiation, given in
14.6.2.1 [temp.dep.type] paragraph 1, is phrased in terms of the
meaning of a name (&#8220;A name refers to the <I>current
instantiation</I> if it is...&#8221;); it does not define when a type
is the current instantiation.  Thus the interpretation of <TT>*this</TT>
and of phrases like &#8220;member of a class that is the current
instantiation&#8221; is not formally specified.</P>

<BR><BR><HR><A NAME="1779"></A><H4>1779.
  
Type dependency of <TT>__func__</TT>
</H4><B>Section: </B>14.6.2.2&#160; [temp.dep.expr]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-25<BR>


<P>The length of the <TT>__func__</TT> array is implementation-defined
but potentially depends on the signature of the function in which it
occurs.  However, <TT>__func__</TT> is not listed among the type-dependent
<I>id-expression</I>s in 14.6.2.2 [temp.dep.expr] paragraph 3.</P>

<BR><BR><HR><A NAME="1028"></A><H4>1028.
  
Dependent names in non-defining declarations
</H4><B>Section: </B>14.6.4&#160; [temp.dep.res]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Sean Hunt
 &#160;&#160;&#160;

 <B>Date: </B>2010-02-03<BR>


<P>The current wording of 14.6.4 [temp.dep.res] seems to assume
that dependent names can only appear in the definition of a template:</P>

<BLOCKQUOTE>

<P>In resolving dependent names, names from the following sources
are considered:</P>

<UL><LI><P>Declarations that are visible at the point of
definition of the template.</P></LI>

<LI><P>Declarations from namespaces associated with the types of
the function arguments both from the instantiation context
(14.6.4.1 [temp.point]) and from the definition context.</P></LI>

</UL>

</BLOCKQUOTE>

<P>However, dependent names can occur in non-defining declarations of
the template as well; for instance,</P>

<PRE>
    template&lt;typename T&gt;
    T foo(T, decltype(bar(T())));
</PRE>

<P><TT>bar</TT> needs to be looked up, even though there is no
definition of <TT>foo</TT> in the translation unit.</P>

<P><B>Additional note (February, 2011):</B></P>

<P>The resolution of this issue can't simply replace the word
&#8220;definition&#8221; with the word &#8220;declaration,&#8221;
<I>mutatis mutandis</I>, because there can be multiple declarations
in a translation unit (which isn't true of &#8220;the definition&#8221;).
As a result, the issue was moved back to "open" status for further
consideration.</P>

<BR><BR><HR><A NAME="1500"></A><H4>1500.
  
Name lookup of dependent conversion function
</H4><B>Section: </B>14.6.4.2&#160; [temp.dep.candidate]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Johannes Schaub
 &#160;&#160;&#160;

 <B>Date: </B>2012-04-27<BR>




<P>Consider the following example:</P>

<PRE>
  template&lt;typename T&gt;
  struct A {
   operator int() { return 0; }

   void f() {
    operator T();
   }
  };

  int main() {
   A&lt;int&gt; a;
   a.f();
  }
</PRE>

<P>One might expect this to call <TT>operator int</TT> when
instantiating. But since <TT>operator T</TT> is a dependent name, it
is looked up by unqualified lookup only in the definition context,
where it will find no declaration. Argument-dependent lookup will not
find anything in the instantiation context either, so this code is
ill-formed. If we change <TT>operator&#160;int()</TT> to
<TT>operator&#160;T()</TT>, which is a seemingly unrelated change, the
code becomes well-formed.</P>

<P>There is implementation variability on this point.</P>

<BR><BR><HR><A NAME="1378"></A><H4>1378.
  
When is an instantiation required?
</H4><B>Section: </B>14.7.1&#160; [temp.inst]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jason Merrill
 &#160;&#160;&#160;

 <B>Date: </B>2011-08-18<BR>




<P>A template instantiation can be &#8220;required&#8221; without
there being a need for it at link time if it can appear in a
constant expression:</P>

<PRE>
    template &lt;class T&gt; struct A {
       static const T t;
    };
    template &lt;class T&gt; const T A&lt;T&gt;::t = 0;
    template &lt;int I&gt; struct B { };
    int a = sizeof(B&lt;A&lt;int&gt;::t&gt;);

    template &lt;class T&gt; constexpr T f(T t) { return t; }
    int b = sizeof(B&lt;f(42)&gt;);
</PRE>

<P>It seems like it might be useful to define a term other than odr-used 
for this sort of use, which is like odr-used but doesn't depend on 
potentially evaluated context or lvalue-rvalue conversions.</P>

<P><U>Nikolay Ivchenkov:</U></P>

<P>Another possibility would be to introduce the extension
described in the closed <A HREF="
     cwg_closed.html#1272">issue 1272</A> and
then change 3.2 [basic.def.odr] paragraph 2 as follows:</P>

<BLOCKQUOTE>

<P>An expression <SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>E</TT></SPAN> is <I>potentially
evaluated</I> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">unless it is an unevaluated operand (Clause
5 [expr]) or a subexpression thereof.</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">if and only if</SPAN></P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>E</TT> is a full-expression, or</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>E</TT> appears in a context where a constant expression
is required, or</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0"><TT>E</TT> is a direct subexpression of a potentially-evaluated
expression and <TT>E</TT> is not an unevaluated operand.</SPAN></P></LI>

</UL>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">An expression <TT>S</TT> is a <I>direct subexpression</I> of an
expression <TT>E</TT> if and only if <TT>S</TT> and <TT>E</TT>
are different expressions, <TT>S</TT> is a subexpression of
<TT>E</TT>, and there is no expression <TT>X</TT> such that
<TT>X</TT> differs from both <TT>S</TT> and <TT>E</TT>,
<TT>S</TT> is a subexpression of <TT>X</TT>, and <TT>X</TT> is a
subexpression of <TT>E</TT>.</SPAN> A variable whose name appears
as a potentially-evaluated expression is <I>odr-used</I>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">unless it is an object that satisfies the requirements for
appearing in a constant expression (5.19 [expr.const])
and the lvalue-to-rvalue conversion (4.1) is immediately
applied</SPAN>...</P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">    template &lt;class T&gt; struct X {
        static int const m = 1;
        static int const n;
    };
    template &lt;class T&gt; int const X&lt;T&gt;::n = 2;

    int main() {
        //<SPAN style="font-family:Times;font-style:italic"> </SPAN>X&lt;void&gt;::m<SPAN style="font-family:Times;font-style:italic"> is odr-used,</SPAN>
        //<SPAN style="font-family:Times;font-style:italic"> </SPAN>X&lt;void&gt;::m<SPAN style="font-family:Times;font-style:italic"> is defined implicitly</SPAN>
        std::cout &lt;&lt; X&lt;void&gt;::m &lt;&lt; std::endl;

        //<SPAN style="font-family:Times;font-style:italic"> </SPAN>X&lt;void&gt;::n<SPAN style="font-family:Times;font-style:italic"> is odr-used,</SPAN>
        //<SPAN style="font-family:Times;font-style:italic"> </SPAN>X&lt;void&gt;::n<SPAN style="font-family:Times;font-style:italic"> is defined explicitly</SPAN>
        std::cout &lt;&lt; X&lt;void&gt;::n &lt;&lt; std::endl;

        //<SPAN style="font-family:Times;font-style:italic"> OK (issue 712 is not relevant here)</SPAN>
        std::cout &lt;&lt; (1 ? X&lt;void&gt;::m : X&lt;void&gt;::n) &lt;&lt; std::endl;
    }
</SPAN></PRE>

</BLOCKQUOTE>

<P>(See also issues <A HREF="
     cwg_defects.html#712">712</A> and
<A HREF="
     cwg_closed.html#1254">1254</A>.)</P>

<BR><BR><HR><A NAME="1602"></A><H4>1602.
  
Linkage of specialization vs linkage of template arguments
</H4><B>Section: </B>14.7.1&#160; [temp.inst]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-01-09<BR>




<P>The Standard does not appear to specify the linkage of a template
specialization.  14.7.1 [temp.inst] paragraph 11 does say,</P>

<BLOCKQUOTE>

Implicitly instantiated class and function template specializations
are placed in the namespace where the template is defined.

</BLOCKQUOTE>

<P>which could be read as implying that the specialization has the
same linkage as the template itself.  Implementation practice seems to
be that the weakst linkage of the template and the arguments is used
for the specialization.</P>

<BR><BR><HR><A NAME="293"></A><H4>293.
  
Syntax of explicit instantiation/specialization too permissive
</H4><B>Section: </B>14.7.2&#160; [temp.explicit]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Mark Mitchell
 &#160;&#160;&#160;

 <B>Date: </B>27 Jun 2001<BR>


<P>14.7.2 [temp.explicit] defines an explicit instantiation as</P>

<UL><I>explicit-instantiation</I>:
<UL><TT>template</TT> <I>declaration</I></UL>
</UL>

<P>Syntactically, that allows things like:</P>
<PRE>
    template int S&lt;int&gt;::i = 5, S&lt;int&gt;::j = 7;
</PRE>

<P>which isn't what anyone actually expects.  As far as I can tell,
nothing in the standard explicitly forbids this, as written.  Syntactically,
this also allows:</P>

<PRE>
    template namespace N { void f(); }
</PRE>

<P>although perhaps the surrounding context is enough to suggest that this is
invalid.</P>

<P><B>Suggested resolution:</B></P>

<P>I think we should say:</P>

<UL><I>explicit-instantiation</I>:
<UL><I>type-specifier-seq</I><SUB>opt</SUB>
    <I>declarator</I><SUB>opt</SUB> <TT>;</TT></UL>
</UL>

<P><I>[Steve Adamczyk: presumably, this should have</I>
<TT>template</TT> <I>at the beginning.]</I></P>

<P>and then say that:</P>

<UL>
<LI>
The declarator can be omitted only when the <I>type-specifier-seq</I>
consists solely of an <I>elaborated-type-specifier</I> for a class type, in
which case the instantiation is for the named class.  If the
declarator is present the instantiation is for the named entity.
</LI>
<LI>
The <I>type-specifier-seq</I> can be omitted only when the declarator
is for a constructor, destructor, or conversion operator.
</LI>
<LI>
The <I>type-specifier-seq</I> cannot define any new types.
</LI>
</UL>

<P>There are similar problems in 14.7.3 [temp.expl.spec]:</P>

<UL><I>explicit-specialization</I>:
<UL><TT>template</TT> &lt;&gt; <I>declaration</I></UL>
</UL>

<P>Here, I think we want:</P>

<UL><I>explicit-specialization</I>:
<UL><I>decl-specifier-seq</I><SUB>opt</SUB> <I>init-declarator</I><SUB>opt</SUB> <TT>;</TT></UL>
</UL>

<P>with similar restrictions as above.</P>

<P><I>[Steve Adamczyk: This also needs to have</I>
<TT>template &lt;&gt;</TT> <I>at the beginning, possibly repeated.]</I></P>



<BR><BR><HR><A NAME="1046"></A><H4>1046.
  
What is a &#8220;use&#8221; of a class specialization?
</H4><B>Section: </B>14.7.2&#160; [temp.explicit]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2010-03-08<BR>


<P>According to 14.7.2 [temp.explicit] paragraph 10,</P>

<BLOCKQUOTE>

An entity that is the subject of an explicit instantiation
declaration and that is also used in the translation unit shall
be the subject of an explicit instantiation definition somewhere
in the program; otherwise the program is ill-formed, no
diagnostic required.

</BLOCKQUOTE>

<P>The term &#8220;used&#8221; is too vague and needs to be defined.
In particular, &#8220;use&#8221; of a class template specialization as
an incomplete type &#8212; to form a pointer, for instance &#8212;
should not require the presence of an explicit instantiation definition
elsewhere in the program.</P>

<BR><BR><HR><A NAME="727"></A><H4>727.
  
In-class explicit specializations
</H4><B>Section: </B>14.7.3&#160; [temp.expl.spec]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Faisal Vali
 &#160;&#160;&#160;

 <B>Date: </B>5 October, 2008<BR>


<P>14.7.3 [temp.expl.spec] paragraph 2 requires that explicit
specializations of member templates be declared in namespace scope, not
in the class definition.  This restriction does not apply to partial
specializations of member templates; that is,</P>

<PRE>
    struct A {
      template&lt;class T&gt; struct B;
      template &lt;class T&gt; struct B&lt;T*&gt; { }; //<SPAN style="font-family:Times;font-style:italic"> well-formed</SPAN>
      template &lt;&gt; struct B&lt;int*&gt; { }; //<SPAN style="font-family:Times;font-style:italic"> ill-formed</SPAN>
    };
</PRE>

<P>There does not seem to be a good reason for this inconsistency.</P>

<P><B>Additional note (October, 2013):</B></P>

<P>EWG has requested CWG to consider resolving this issue.  See EWG
issue 41.</P>

<BR><BR><HR><A NAME="1792"></A><H4>1792.
  
Incorrect example of explicit specialization of member enumeration
</H4><B>Section: </B>14.7.3&#160; [temp.expl.spec]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>2013-10-01<BR>


<P>The example in 14.7.3 [temp.expl.spec] paragraph 6 reads, in
part,</P>

<PRE>
  template&lt;class T&gt; struct A {
    enum E : T;
    enum class S : T;
  };
  template&lt;&gt; enum A&lt;int&gt;::E : int { eint };         //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
  template&lt;&gt; enum class A&lt;int&gt;::S : int { sint };   //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
  template&lt;class T&gt; enum A&lt;T&gt;::E : T { eT };
  template&lt;class T&gt; enum class A&lt;T&gt;::S : T { sT };
  template&lt;&gt; enum A&lt;char&gt;::E : int { echar };       //<SPAN style="font-family:Times;font-style:italic"> ill-formed, </SPAN>A&lt;char&gt;::E<SPAN style="font-family:Times;font-style:italic"> was instantiated</SPAN>
                                                    //<SPAN style="font-family:Times;font-style:italic"> when </SPAN>A&lt;char&gt;<SPAN style="font-family:Times;font-style:italic"> was instantiated</SPAN>
  template&lt;&gt; enum class A&lt;char&gt;::S : int { schar }; //<SPAN style="font-family:Times;font-style:italic"> OK</SPAN>
</PRE>

<P>The <TT>int</TT> <I>enum-base</I> in the last two lines appears to
be incorrect; the reference to <TT>A&lt;char&gt;</TT> in the
<I>nested-name-specifier</I> will have instantiated the declarations
of <TT>E</TT> and <TT>S</TT> with an <I>enum-base</I> of <TT>char</TT>,
and the explicit specializations must agree.</P>

<BR><BR><HR><A NAME="264"></A><H4>264.
  
Unusable template constructors and conversion functions
</H4><B>Section: </B>14.8.1&#160; [temp.arg.explicit]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>17 Nov 2000<BR>




<P>The note in paragraph 5 of 14.8.1 [temp.arg.explicit] makes
clear that explicit template arguments cannot be supplied in
invocations of constructors and conversion functions because they are
called without using a name.  However, there is nothing in the current
wording of the Standard that makes declaring a constructor or
conversion operator that is unusable because of nondeduced parameters
(i.e., that would need to be specified explicitly) ill-formed.  It
would be a service to the programmer to diagnose this useless
construct as early as possible.</P>

<BR><BR><HR><A NAME="271"></A><H4>271.
  
Explicit instantiation and template argument deduction
</H4><B>Section: </B>14.8.2&#160; [temp.deduct]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>John Spicer
 &#160;&#160;&#160;

 <B>Date: </B>20 Feb 2001<BR>




<P>Nicolai Josuttis sent me an example like the following:</P>

<PRE>
    template &lt;typename RET, typename T1, typename T2&gt;
    const RET&amp; min (const T1&amp; a, const T2&amp; b)
    {
	return (a &lt; b ? a : b);
    }
    template const int&amp; min&lt;int&gt;(const int&amp;,const int&amp;);  // #1
    template const int&amp; min(const int&amp;,const int&amp;);       // #2
</PRE>

<P>Among the questions was whether explicit instantiation #2 is valid,
where deduction is required to determine the type of <TT>RET</TT>.</P>

<P>The first thing I realized when researching this is that the standard
does not really spell out the rules for deduction in declarative
contexts (friend declarations, explicit specializations, and
explicit instantiations).  For explicit instantiations,
14.7.2 [temp.explicit] paragraph 2 does
mention deduction, but it doesn't say which set of deduction rules from
14.8.2 [temp.deduct] should be applied.</P>

<P>Second, Nicolai pointed out that
14.7.2 [temp.explicit] paragraph 6 says</P>

<BLOCKQUOTE>
A trailing <I>template-argument</I>
can be left unspecified in an explicit instantiation provided it can
be deduced from the type of a function parameter
(14.8.2 [temp.deduct]).
</BLOCKQUOTE>

<P>This prohibits cases
like #2, but I believe this was not considered in the wording as there
is no reason not to include the return type in the deduction process.</P>

<P>I think there may have been some confusion because the return type is
excluded when doing deduction on a function call.  But there are
contexts where the return type is included in deduction, for example,
when taking the address of a function template specialization.</P>

<P><U>Suggested resolution</U>:</P>

<OL>

<LI>Update 14.8.2 [temp.deduct] to include a section
"Deducing template arguments from a declaration" that describes how
deduction is done when finding a template that matches a declaration.
This should, I believe, include the return type.</LI>

<LI>Update 14.7.2 [temp.explicit] to make reference to the new
rules in 14.8.2 [temp.deduct] and remove the description of
the deduction details from 14.7.2 [temp.explicit] paragraph
6.</LI>

</OL>
<BR><BR><HR><A NAME="297"></A><H4>297.
  
Which template does an explicit specialization specialize?
</H4><B>Section: </B>14.8.2&#160; [temp.deduct]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Andrei Iltchenko
 &#160;&#160;&#160;

 <B>Date: </B>7 Jul 2001<BR>


<P>Andrei Iltchenko points out that the standard has no wording that
defines how to determine which template is specialized by an
explicit specialization of a function template.
He suggests "template argument deduction
in such cases proceeds in the same way as when taking the address
of a function template,
which is described in 14.8.2.2 [temp.deduct.funcaddr]."</P>

<P>John Spicer points out that the same problem exists for all
similar declarations, i.e., friend declarations and explicit
instantiation directives.  Finding a corresponding placement
<TT>operator delete</TT> may have a similar problem.</P>

<P><U>John Spicer</U>:
There are two aspects of "determining which template" is referred to by
a declaration: determining the function template associated with the
named specialization, and determining the values of the template arguments
of the specialization.</P>
<PRE>
    template &lt;class T&gt; void f(T);  #1
    template &lt;class T&gt; void f(T*); #2
    template &lt;&gt; void f(int*);
</PRE>

<P>In other words, which <TT>f</TT> is being specialized (#1 or #2)?
And then, what are the deduced template arguments?</P>

<P>14.5.6.2 [temp.func.order] does say that partial ordering is
done in contexts such as this.
Is this sufficient, or do we need to say more about the selection of the
function template to be selected? </P>

<P>14.8.2 [temp.deduct] probably needs a new section to cover
argument deduction for cases like this.</P>

<BR><BR><HR><A NAME="697"></A><H4>697.
  
Deduction rules apply to more than functions
</H4><B>Section: </B>14.8.2&#160; [temp.deduct]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Doug Gregor
 &#160;&#160;&#160;

 <B>Date: </B>6 June, 2008<BR>




<P>14.8.2 [temp.deduct] is all about function types, but these
rules also apply, e.g., when matching a class template partial
specialization.  We should add a note stating that we could be doing
substitution into the <I>template-id</I> for a class template partial
specialization.</P>

<P><B>Additional note (August 2008):</B></P>

<P>According to 14.5.5.1 [temp.class.spec.match] paragraph 2, argument
deduction is used to determine whether a given partial specialization
matches a given argument list.  However, there is nothing in
14.5.5.1 [temp.class.spec.match] nor in 14.8.2 [temp.deduct] and
its subsections that describes exactly how argument deduction is to
be performed in this case.  It would seem that more than just a note
is required to clarify this processing.</P>

<BR><BR><HR><A NAME="503"></A><H4>503.
  
Cv-qualified function types in template argument deduction
</H4><B>Section: </B>14.8.2.1&#160; [temp.deduct.call]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Gabriel Dos Reis
 &#160;&#160;&#160;

 <B>Date: </B>22 Feb 2005<BR>




<P>Consider the following program:</P>

<PRE>
    template &lt;typename T&gt; int ref (T&amp;)                { return 0; }
    template &lt;typename T&gt; int ref (const T&amp;)          { return 1; }
    template &lt;typename T&gt; int ref (const volatile T&amp;) { return 2; }
    template &lt;typename T&gt; int ref (volatile T&amp;)       { return 4; }

    template &lt;typename T&gt; int ptr (T*)                { return 0; }
    template &lt;typename T&gt; int ptr (const T*)          { return 8; }
    template &lt;typename T&gt; int ptr (const volatile T*) { return 16; }
    template &lt;typename T&gt; int ptr (volatile T*)       { return 32; }

    void foo() {}

    int main()
    {
        return ref(foo) + ptr(&amp;foo);
    }
</PRE>

<P>The Standard appears to specify that the value returned from
<TT>main</TT> is 2.  The reason for this result is that references and
pointers are handled differently in template argument deduction.</P>

<P>For the reference case, 14.8.2.1 [temp.deduct.call] paragraph
3 says that &#8220;If <TT>P</TT> is a reference type, the type
referred to by <TT>P</TT> is used for type deduction.&#8221; Because
of <A HREF="
     cwg_defects.html#295">issue 295</A>, all four of the types for the
<TT>ref</TT> function parameters are the same, with no
cv-qualification; overload resolution does not find a best match among
the parameters and thus the most-specialized function is selected.</P>

<P>For the pointer type, argument deduction does not get as far as
forming a cv-qualified function type; instead, argument deduction
fails in the cv-qualified cases because of the cv-qualification
mismatch, and only the cv-unqualified version of <TT>ptr</TT> survives
as a viable function.</P>

<P>I think the choice of ignoring cv-qualifiers in the reference case
but not the pointer case is very troublesome.  The reason is that when
one considers function objects as function parameters, it introduces a
semantic difference whether the function parameter is declared a
reference or a pointer.  In all other contexts, it does not matter: a
function name decays to a pointer and the resulting semantics are the
same.</P>

<P>(See also <A HREF="
     cwg_active.html#1584">issue 1584</A>.)</P>
<BR><BR><HR><A NAME="1221"></A><H4>1221.
  
Partial ordering and reference collapsing
</H4><B>Section: </B>14.8.2.4&#160; [temp.deduct.partial]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>2010-11-08<BR>


<P>The current partial ordering rules produce surprising results in
the presence of reference collapsing. </P>

<P>Since partial ordering is currently based solely on the signature
of the function templates, the lack of difference following
substitution of the template type parameter in the following is not
taken into account.</P>

<P>Especially unsettling is that the allegedly "more specialized"
template (#2) is not a candidate in the first call where template
argument deduction fails for it despite a lack of non-deduced
contexts.</P>

<PRE>
    template &lt;typename T&gt;
    void foo(T&amp;&amp;);  // #1

    template &lt;typename T&gt;
    void foo(volatile T&amp;&amp;);  // #2

    int main(void) {
      const int x = 0;
      foo(x);  // calls #1 with T='const int &amp;'
      foo&lt;const int &amp;&gt;(x);  // calls #2
    }
</PRE>

<BR><BR><HR><A NAME="1763"></A><H4>1763.
  
Length mismatch in template type deduction
</H4><B>Section: </B>14.8.2.5&#160; [temp.deduct.type]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Canada
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-23<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA4">N3690 comment
  CA&#160;4<BR></A>

<P>It is not clear how an example like the following is to be handled:</P>

<PRE>
  template &lt;typename U&gt; 
  struct A { 
    template &lt;typename V&gt; operator A&lt;V&gt;(); 
  }; 

  template &lt;typename T&gt; 
  void foo(A&lt;void (T)&gt;); 

  void foo(); 

  int main() { 
    A&lt;void (int, char)&gt; a; 
    foo&lt;int&gt;(a); 
    foo(a); //<SPAN style="font-family:Times;font-style:italic"> deduces </SPAN>T<SPAN style="font-family:Times;font-style:italic"> to be </SPAN>int
  } 
</PRE>

<P>In subclause 14.8.2.5 [temp.deduct.type] paragraph 10, deduction from
a function type considers P/A pairs from the parameter-type-list only where
the "P" function type has a parameter.  Deduction is not specified to fail
if there are additional parameters in the corresponding "A" function
type.</P>

<P><B>Notes from the September, 2013 meeting:</B></P>

<P>CWG agreed that this example should not be accepted.  The existing
rules seem to cover this case (deduction is not specified to
&#8220;succeed,&#8221; so it's a reasonable conclusion that it fails),
but it might be helpful to be clearer.</P>

<BR><BR><HR><A NAME="1774"></A><H4>1774.
  
Discrepancy between subobject destruction and stack unwinding
</H4><B>Section: </B>15.2&#160; [except.ctor]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Canada
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-24<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3770.html#CA24">N3690 comment
  CA&#160;24<BR></A>

<P>The current wording of 15.5.1 [except.terminate] paragraph 2
affords implementations a significant degree of freedom when exception
handling results in a call to <TT>std::terminate:</TT></P>

<BLOCKQUOTE>

In the situation where no matching handler is found, it is
implementation-defined whether or not the stack is unwound before
<TT>std::terminate()</TT> is called. In the situation where the search for
a handler (15.3 [except.handle]) encounters the outermost block of a
function with a <I>noexcept-specification</I> that does not allow the
exception (15.4 [except.spec]), it is implementation-defined whether
the stack is unwound, unwound partially, or not unwound at all before
<TT>std::terminate()</TT> is called. In all other situations, the stack
shall not be unwound before std::terminate() is called.

</BLOCKQUOTE>

<P>This contrasts with the treatment of subobjects and objects constructed
via delegating constructos in 15.2 [except.ctor] paragraph 2:</P>

<BLOCKQUOTE>

An object of any storage duration whose initialization or destruction is
terminated by an exception will have destructors executed for all of its
fully constructed subobjects (excluding the variant members of a union-like
class), that is, for subobjects for which the principal constructor
(12.6.2 [class.base.init]) has completed execution and the destructor
has not yet begun execution. Similarly, if the non-delegating constructor
for an object has completed execution and a delegating constructor for that
object exits with an exception, the object's destructor will be invoked.

</BLOCKQUOTE>

<P>Here the destructors must be called.  It would be helpful if these
requirements were harmonized.</P>

<P><B>Notes from the September, 2013 meeting:</B></P>

<P>Although the Canadian NB comment principally was a request to reconsider
the resolution of <A HREF="
     cwg_defects.html#1424">issue 1424</A>, which CWG decided
to retain, the comment also raised the question above, which CWG felt
merited its own issue.</P>

<BR><BR><HR><A NAME="1777"></A><H4>1777.
  
Empty pack expansion in <I>dynamic-exception-specification</I>
</H4><B>Section: </B>15.4&#160; [except.spec]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Richard Smith
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-24<BR>




<P>According to 14.5.3 [temp.variadic] paragraph 6, describing
an empty pack expansion,</P>

<BLOCKQUOTE>

When <I>N</I> is zero, the instantiation of the expansion produces an empty
list. Such an instantiation does not alter the syntactic interpretation of
the enclosing construct, even in cases where omitting the list entirely
would otherwise be ill-formed or would result in an ambiguity in the
grammar.

</BLOCKQUOTE>

<P>This leaves open the question of whether something like</P>

<PRE>
  template&lt;typename...T&gt; void f() throw(T...);
</PRE>

<P>should be considered to have a non-throwing
<I>exception-specification</I> when <TT>T...</TT> is empty.  The definition
in 15.4 [except.spec] paragraph 12 appears to be syntactic
regarding <I>dynamic-exception-specification</I>s:</P>

<BLOCKQUOTE>

An <I>exception-specification</I> is <I>non-throwing</I> if it is of the
form <TT>throw()</TT>, <TT>noexcept</TT>,
or <TT>noexcept(</TT><I>constant-expression</I> <TT>)</TT> where
the <I>constant-expression</I> yields <TT>true</TT>. A function with a
non-throwing <I>exception-specification</I> does not allow any exceptions.

</BLOCKQUOTE>

<P>It seems evident, however, that a <I>dynamic-exception-specification</I>
with an empty pack expansion &#8220;does not allow any exceptions.&#8221;</P>

<BR><BR><HR><A NAME="596"></A><H4>596.
  
Replacing an exception object
</H4><B>Section: </B>15.5.2&#160; [except.unexpected]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>12 September 2006<BR>


<P>When a function throws an exception that is not in its
<I>exception-specification</I>, <TT>std::unexpected()</TT> is called.
According to 15.5.2 [except.unexpected] paragraph 2,</P>

<BLOCKQUOTE>

If [<TT>std::unexpected()</TT>] throws or rethrows an exception that
the <I>exception-specification</I> does not allow then the following
happens: If the <I>exception-specification</I> does not include the class
<TT>std::bad_exception</TT> (18.8.2 [bad.exception]) then
the function <TT>std::terminate()</TT> is called, otherwise the thrown
exception is replaced by an implementation-defined object of the type
<TT>std::bad_exception,</TT> and the search for another handler will
continue at the call of the function
whose <I>exception-specification</I> was violated.

</BLOCKQUOTE>

<P>The &#8220;replaced by&#8221; wording is imprecise and undefined.
For example, does this mean that the destructor is called for the
existing exception object, or is it simply abandoned?  Is the
replacement <I>in situ</I>, so that a pointer to the existing
exception object will now point to the <TT>std::bad_exception</TT>
object?</P>

<P><U>Mike Miller</U>: The call to <TT>std::unexpected()</TT> is
not described as analogous to invoking a handler, but if it were,
that would resolve this question; it is clearly specified what
happens to the previous exception object when a new exception is
thrown from a handler (15.1 [except.throw] paragraph 4).</P>

<P>This approach would also clarify other questions that have been
raised regarding the requirements for stack unwinding.  For
example, 15.5.1 [except.terminate] paragraph 2 says that</P>

<BLOCKQUOTE>

In the situation where no matching handler is found, it is
implementation-defined whether or not the stack is unwound before
<TT>std::terminate()</TT> is called.

</BLOCKQUOTE>

<P>This requirement could be viewed as in conflict with the statement
in 15.5.2 [except.unexpected] paragraph 1 that</P>

<BLOCKQUOTE>

If a function with an <I>exception-specification</I> throws an exception that
is not listed in the <I>exception-specification</I>, the function
<TT>std::unexpected()</TT> is called (D.11 [exception.unexpected])
immediately after completing the stack unwinding for the former
function.

</BLOCKQUOTE>

<P>If it is implementation-defined whether stack unwinding occurs before
calling <TT>std::terminate()</TT> and <TT>std::unexpected()</TT> is
called only after doing stack unwinding, does that mean that it is
implementation-defined whether <TT>std::unexpected()</TT> is called
if there is ultimately no handler found?</P>

<P>Again, if invoking <TT>std::unexpected()</TT> were viewed as
essentially invoking a handler, the answer to this would be clear,
because unwinding occurs before invoking a handler.</P>

<BR><BR><HR><A NAME="925"></A><H4>925.
  
Type of character literals in preprocessor expressions
</H4><B>Section: </B>16.1&#160; [cpp.cond]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Michael Wong
 &#160;&#160;&#160;

 <B>Date: </B>29 June, 2009<BR>


<P>According to 16.1 [cpp.cond] paragraph 4,</P>

<BLOCKQUOTE>

The resulting tokens comprise the controlling constant expression
which is evaluated according to the rules of 5.19 [expr.const]
using arithmetic that has at least the ranges specified in
18.3 [support.limits], except that all signed and unsigned integer
types act as if they have the same representation as, respectively,
<TT>intmax_t</TT> or <TT>uintmax_t</TT> (_N3035_.18.4.2 [stdinth]).
This includes interpreting character literals, which may involve
converting escape sequences into execution character set members.

</BLOCKQUOTE>

<P>Ordinary character literals with a single <I>c-char</I> have the
type <TT>char</TT>, which is neither a signed nor an unsigned integer
type. Although 4.5 [conv.prom] paragraph 1 is clear that
<TT>char</TT> values promote to <TT>int</TT>, regardless of whether
the implementation treats <TT>char</TT> as having the values of
<TT>signed char</TT> or <TT>unsigned char</TT>, 16.1 [cpp.cond] paragraph 4 isn't clear on whether character literals
should be treated as signed or unsigned values.  In C99, such
literals have type <TT>int</TT>, so the question does not arise.
If an implementation in which plain <TT>char</TT> has the values of
<TT>unsigned char</TT> were to treat character literals as unsigned,
an expression like <TT>'0'-'1'</TT> would thus have different values
in C and C++, namely -1 in C and some large unsigned value in C++.</P>

<BR><BR><HR><A NAME="1718"></A><H4>1718.
  
Macro invocation spanning end-of-file
</H4><B>Section: </B>16.3&#160; [cpp.replace]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>David Krauss
 &#160;&#160;&#160;

 <B>Date: </B>2013-07-23<BR>


<P>Although it seems to be common implementation practice to reject
a macro invocation that begins in a header file and whose closing
right parenthesis appears in the file that included it, there does
not seem to be a prohibition of this case in the specification of
function-style macros.  Should this be accepted?</P>

<BR><BR><HR><A NAME="1625"></A><H4>1625.
  
Adding spaces between tokens in stringizing
</H4><B>Section: </B>16.3.2&#160; [cpp.stringize]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Chandler Carruth
 &#160;&#160;&#160;

 <B>Date: </B>2013-02-18<BR>




<P>Given the following input,</P>

<PRE>
  #define F(A, B, C) A ## x.B ## y.C ## z
  #define STRINGIFY(x) #x
  #define EXPAND_AND_STRINGIFY(x) STRINGIFY(x)
  char v[] = EXPAND_AND_STRINGIFY(F(a, b, c))
</PRE>

<P>there is implementation variance in the value of <TT>v</TT>: some
produce the string <TT>"ax.by.cz"</TT> and others produce the string
<TT>"ax. by. cz"</TT>.  Although 16.3.2 [cpp.stringize] paragraph 2 is
explicit in its treatment of leading and trailing white space, it is not
clear whether there is latitude for inserting spaces between tokens, as
some implementations do, since the description otherwise is written solely
in terms of preprocessing tokens.  There may be cases in which such spaces
would be needed to preserve the original tokenization, but it is not clear
whether the result of stringization needs to produce something that would
lex to the same tokens.</P>

<P><B>Notes from the April, 2013 meeting:</B></P>

<P>Because the preprocessor specification is primarily copied directly
from the C Standard, this issue has been referred to the C liaison for
consultation with WG14.</P>

<BR><BR><HR><A NAME="268"></A><H4>268.
  
Macro name suppression in rescanned replacement text
</H4><B>Section: </B>16.3.4&#160; [cpp.rescan]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Bjarne Stroustrup
 &#160;&#160;&#160;

 <B>Date: </B>18 Jan 2001<BR>




<P>It is not clear from the Standard what the result of the
following example should be:</P>

<BLOCKQUOTE>
<PRE>
#define NIL(xxx) xxx
#define G_0(arg) NIL(G_1)(arg)
#define G_1(arg) NIL(arg)
G_0(42)
</PRE>
</BLOCKQUOTE>

<P>The relevant text from the Standard is found in
16.3.4 [cpp.rescan] paragraph 2:</P>

<BLOCKQUOTE>

If the name of the macro being replaced is found during this scan of
the replacement list (not including the rest of the source file's
preprocessing tokens), it is not replaced. Further, if any nested
replacements encounter the name of the macro being replaced, it is not
replaced. These nonreplaced macro name preprocessing tokens are no
longer available for further replacement even if they are later
(re)examined in contexts in which that macro name preprocessing token
would otherwise have been replaced.

</BLOCKQUOTE>

<P>The sequence of expansion of <TT>G0(42)</TT> is as follows:</P>

<BLOCKQUOTE>
<PRE>
G0(42)
NIL(G_1)(42)
G_1(42)
NIL(42)
</PRE>
</BLOCKQUOTE>

<P>The question is whether the use of <TT>NIL</TT> in the last
line of this sequence qualifies for non-replacement under the
cited text.  If it does, the result will be <TT>NIL(42)</TT>.  If
it does not, the result will be simply <TT>42</TT>.</P>

<P>The original intent of the J11 committee in this text was
that the result should be <TT>42</TT>, as demonstrated by the
original pseudo-code description of the replacement algorithm
provided by Dave Prosser, its author.

The English description,
however, omits some of the subtleties of the pseudo-code and
thus arguably gives an incorrect answer for this case.</P>

<P><U>Suggested resolution (Mike Miller)</U>: Replace the cited
paragraph with the following:</P>

<BLOCKQUOTE>

<P>As long as the scan involves only preprocessing tokens from
a given macro's replacement list, or tokens resulting from a
replacement of those tokens, an occurrence of the macro's name
will not result in further replacement, even if it is later
(re)examined in contexts in which that macro name preprocessing
token would otherwise have been replaced.</P>

<P>Once the scan reaches the preprocessing token following a
macro's replacement list &#8212; including as part of the
argument list for that or another macro &#8212; the macro's
name is once again available for replacement.  [<I>Example:</I></P>

<PRE>
    #define NIL(xxx) xxx
    #define G_0(arg) NIL(G_1)(arg)
    #define G_1(arg) NIL(arg)
    G_0(42)                         // result is 42, not NIL(42)
</PRE>

<P>The reason that <TT>NIL(42)</TT> is replaced is that <TT>(42)</TT>
comes from outside the replacement list of <TT>NIL(G_1)</TT>, hence
the occurrence of <TT>NIL</TT> within the replacement list for
<TT>NIL(G_1)</TT> (via the replacement of <TT>G_1(42)</TT>) is not
marked as nonreplaceable.  <I>&#8212;end example</I>]</P>

</BLOCKQUOTE>

<P>(Note: The resolution of this issue must be coordinated with
J11/WG14.)</P>

<P><B>Notes (via Tom Plum) from April, 2004 WG14 Meeting:</B></P>

<P>Back in the 1980's it was understood by several WG14 people
that there were tiny differences between the "non-replacement"
verbiage and the attempts to produce pseudo-code.  The
committee's decision was that no realistic programs "in the wild"
would venture into this area, and trying to reduce the
uncertainties is not worth the risk of changing conformance
status of implementations or programs.</P>

<BR><BR><HR><A NAME="745"></A><H4>745.
  
Effect of ill-formedness resulting from <TT>#error</TT>
</H4><B>Section: </B>16.5&#160; [cpp.error]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Clark Nelson
 &#160;&#160;&#160;

 <B>Date: </B>13 November, 2008<BR>


<P>C99 is very clear that a <TT>#error</TT> directive causes a translation
to fail: Clause 4 paragraph 4 says,</P>

<BLOCKQUOTE>

The implementation shall not successfully translate a preprocessing
translation unit containing a <TT>#error</TT> preprocessing directive
unless it is part of a group skipped by conditional inclusion.

</BLOCKQUOTE>

<P>C++, on the other hand, simply says that a <TT>#error</TT> directive
&#8220;renders the program ill-formed&#8221; (16.5 [cpp.error]),
and the only requirement for an ill-formed program is that a diagnostic
be issued; the translation may continue and succeed.  (Noted in passing:
if this difference between C99 and C++ is addressed, it would be helpful
for synchronization purposes in other contexts as well to introduce the
term &#8220;preprocessing translation unit.&#8221;)</P>

<BR><BR><HR><A NAME="897"></A><H4>897.
  
<TT>_Pragma</TT> and extended <I>string-literal</I>s
</H4><B>Section: </B>16.9&#160; [cpp.pragma.op]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>9 May, 2009<BR>




<P>The specification of how the <I>string-literal</I> in a <TT>_Pragma</TT>
operator is handled does not deal with the new kinds of string literals.
16.9 [cpp.pragma.op] says,</P>

<BLOCKQUOTE>

The string literal is <I>destringized</I> by deleting the <TT>L</TT>
prefix, if present, deleting the leading and trailing double-quotes,
replacing each escape sequence...

</BLOCKQUOTE>

<P>The various other prefixes should either be handled or prohibited.</P>



<P><B>Additional note (October, 2013):</B></P>

<P>If raw string literals are supported, the question of how to handle
line splicing is relevant.  The wording says that &#8220;the characters
are processed through translation phase 3,&#8221; which is a bit
ambiguous as to whether that includes phases 1 and 2 or not.  It would
be better to be explicit and say that the processing of phase 3 or of
phases 1 through 3 is applied.</P>

<BR><BR><HR><A NAME="1248"></A><H4>1248.
  
Updating Annex C to C99
</H4><B>Section: </B>C.1&#160; [diff.iso]
 &#160;&#160;&#160;

 <B>Status: </B>open
 &#160;&#160;&#160;

 <B>Submitter: </B>Jonathan Wakely
 &#160;&#160;&#160;

 <B>Date: </B>2011-02-28<BR>




<P>The description of incompatibilities with C in Annex
C.1 [diff.iso] refers to C89, but there are a number of
new features in C99 that should be covered.</P>



<BR><BR><BR><BR><HR><A NAME="Concurrency Status"></A><H3>Issues with "Concurrency" Status</H3>
<HR><A NAME="1441"></A><H4>1441.
  
Unclear wording for signal handler restrictions
</H4><B>Section: </B>1.9&#160; [intro.execution]
 &#160;&#160;&#160;

 <B>Status: </B>concurrency
 &#160;&#160;&#160;

 <B>Submitter: </B>Alisdair Meredith
 &#160;&#160;&#160;

 <B>Date: </B>2012-01-06<BR>




<P>The wording of 1.9 [intro.execution] paragraph 6 is
intended to describe the values of objects upon entry to and exit
from the handler &#8212; i.e., that signal handler cannot rely on
non-atomic objects being in a consistent state upon entry, nor
can it reliably set the value of non-atomic objects and expect
that they will continue to have those values after the handler
exits.  However, the wording could be read as saying even during
the execution of the handler it cannot set and use non-atomic
objects.  The wording should be clarified.</P>

<BR><BR><HR><A NAME="1466"></A><H4>1466.
  
Visible sequences of side effects are redundant
</H4><B>Section: </B>1.10&#160; [intro.multithread]
 &#160;&#160;&#160;

 <B>Status: </B>concurrency
 &#160;&#160;&#160;

 <B>Submitter: </B>Mark Batty
 &#160;&#160;&#160;

 <B>Date: </B>2012-02-21<BR>


<P><I>[The following is reproduced verbatim from WG14 DR406 as a C-liaison
issue.]</I></P>

<P>It has been mathematically proved that a simplification can be made
to the memory model as it is specified in the final draft of the C++11
standard. Essentially, the restriction defining <I>visible sequence of
side effects</I> (vsse) is redundant and can be removed with no ill
effects. The main motivation for doing this is that the current
restriction is misleading. 5.1.2.4p22 defines vsse's: </P>

<BLOCKQUOTE>

The visible sequence of side effects on an atomic object M, with
respect to a value computation B of M, is a maximal contiguous
sub-sequence of side effects in the modification order of M, where the
first side effect is visible with respect to B, and for every
subsequent side effect, it is not the case that B happens before
it. The value of an atomic object M, as determined by evaluation B,
shall be the value stored by some operation in the visible sequence of
M with respect to B.

</BLOCKQUOTE>

<P>The wording of this paragraph makes it seem as if the vsse
identifies the writes that an atomic read is allowed to read from, but
this is not the case. There can be writes in the vsse that cannot be
read due to the coherence requirements (to be included in C, 1.10p15
through 1.10p18 in C++ N3291). Consequently this is even more
confusing than it at first appears. </P>

<P>Also propose changing 5.1.2.4p22 to the following:</P>

<BLOCKQUOTE>

The value of an atomic object M, as determined by evaluation B, shall
be the value stored by some side effect A that modifies M, where B
does not happen before A.

</BLOCKQUOTE>

<P>With a note to remind the reader of the coherence requirements: </P>

<BLOCKQUOTE>

NOTE: The set of side effects that a given evaluation might take its
value from is also restricted by the rest of the rules described here,
and in particular, by the coherence requirements below

</BLOCKQUOTE>

<P>If the committee is concerned about allowing a differing text from C++11, then a note could be added to assure the reader: </P>

<BLOCKQUOTE>

NOTE: Although the rules for multi-threaded executions differ here
from those of C++11, the executions they allow are precisely the
same. Visible sequences of side effects are a redundant restriction.

</BLOCKQUOTE>

<P><B>Proposed resolution (September, 2013):</B></P>

<OL><LI><P>Change 1.10 [intro.multithread] paragraph 14 as follows:</P></LI>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">The <I>visible sequence of side effects</I> on an atomic
object <I>M</I>, with respect to a value computation <I>B</I> of <I>M</I>,
is a maximal contiguous sub-sequence of side effects in the modification
order of M, where the first side effect is visible with respect
to <I>B</I>, and for every side effect, it is not the case that <I>B</I>
happens before it.</SPAN> The value of an atomic object <I>M</I>, as
determined by evaluation <I>B</I>, shall be the value stored by
some <SPAN style="text-decoration:line-through;background-color:#FFA0A0">operation in the visible sequence of <I>M</I> with respect
to <I>B</I></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">side effect <I>A</I> that modifies <I>M</I>,
where <I>B</I> does not happen before <I>A</I></SPAN>. [<I>Note:</I> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">It
can be shown that the visible sequence of side effects of a value
computation is unique given</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">The set of side effects that a given
evaluation might take its value from is also restricted by the rest of the
rules described here, and in particular, by</SPAN> the coherence
requirements below. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<LI><P>Change 1.10 [intro.multithread] paragraph 20 as follows:</P></LI>

<BLOCKQUOTE>

[<I>Note:</I> The <SPAN style="text-decoration:line-through;background-color:#FFA0A0">visible sequence of side effects</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">value
observed by a load of an atomic</SPAN> depends on the &#8220;happens
before&#8221; relation, which depends on the values observed by loads of
atomics<SPAN style="text-decoration:line-through;background-color:#FFA0A0">, which we are restricting here</SPAN>. The intended reading is
that there must exist an association of atomic loads with modifications
they observe that, together with suitably chosen modification orders and
the &#8220;happens before&#8221; relation derived as described above,
satisfy the resulting constraints as imposed here. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<LI><P>Change 1.10 [intro.multithread] paragraph 22 as follows:</P></LI>

<BLOCKQUOTE>

[<I>Note:</I> Compiler transformations that introduce assignments to a
potentially shared memory location that would not be modified by the
abstract machine are generally precluded by this standard, since such an
assignment might overwrite another assignment by a different thread in
cases in which an abstract machine execution would not have encountered a
data race. This includes implementations of data member assignment that
overwrite adjacent members in separate memory locations. Reordering of
atomic loads in cases in which the atomics in question may alias is also
generally precluded, since this may violate the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">&#8220;visible
sequence&#8221;</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">coherence</SPAN> rules. &#8212;<I>end note</I>]

</BLOCKQUOTE>

<LI><P>Change 29.3 [atomics.order] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

<P>There shall be a single total order <I>S</I> on all
<TT>memory_order_seq_cst</TT> operations, consistent with the
&#8220;happens before&#8221; order and modification orders for all affected
locations, such that each <TT>memory_order_seq_cst</TT>
operation <I>B</I> that loads a value from an atomic object <I>M</I>
observes one of the following values:</P>

<UL><LI><P>the result of the last modification <I>A</I> of <I>M</I> that
precedes <I>B</I> in <I>S</I>, if it exists, or</P></LI>

<LI><P>if <I>A</I> exists, the result of some modification
of <I>M</I> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">in the visible sequence of side effects</SPAN> with respect
to <I>B</I> that is not <TT>memory_order_seq_cst</TT> and that does not
happen before <I>A</I>, or</P></LI>

<LI><P>if <I>A</I> does not exist, the result of some modification
of <I>M</I> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">in the visible sequence of side effects</SPAN> with respect
to <I>B</I> that is not <TT>memory_order_seq_cst</TT>.</P></LI>

</UL>

<P>[<I>Note:</I>...</P>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1661"></A><H4>1661.
  
Preservation of infinite loops
</H4><B>Section: </B>1.10&#160; [intro.multithread]
 &#160;&#160;&#160;

 <B>Status: </B>concurrency
 &#160;&#160;&#160;

 <B>Submitter: </B>Daniel Kr&#252;gler
 &#160;&#160;&#160;

 <B>Date: </B>2013-04-15<BR>




<P>According to 1.10 [intro.multithread] paragraph 24,</P>

<BLOCKQUOTE>

<P>The implementation may assume that any thread will eventually do one of
the following:</P>

<UL><LI><P>terminate,</P></LI>

<LI><P>make a call to a library I/O function,</P></LI>

<LI><P>access or modify a volatile object, or</P></LI>

<LI><P>perform a synchronization operation or an atomic operation.</P></LI>

</UL>

<P>[<I>Note:</I> This is intended to allow compiler transformations such as
removal of empty loops, even when termination cannot be
proven. &#8212;<I>end note</I>]</P>

</BLOCKQUOTE>

<P>Some programmers find this liberty afforded to implementations to
be disadvantageous; see <A HREF="http://blog.regehr.org/archives/161">
this blog post</A> for a discussion of the subject.</P>

<BR><BR><HR><A NAME="1784"></A><H4>1784.
  
Concurrent execution during static local initialization
</H4><B>Section: </B>6.7&#160; [stmt.dcl]
 &#160;&#160;&#160;

 <B>Status: </B>concurrency
 &#160;&#160;&#160;

 <B>Submitter: </B>Jens Maurer
 &#160;&#160;&#160;

 <B>Date: </B>2013-09-27<BR>


<P>Regarding initialization of a block-scope static variable,
6.7 [stmt.dcl] paragraph 4 says,</P>

<BLOCKQUOTE>

If control enters the declaration concurrently while the variable is being
initialized, the concurrent execution shall wait for completion of the
initialization.

</BLOCKQUOTE>

<P>This specification does not use the terminology of
1.10 [intro.multithread], so the meaning of &#8220;wait&#8221; is not
clear.  For example, will a concurrent thread that &#8220;waited&#8221;
see (in the sense of happens-before) the result of the initialization
(including side effects caused during the initialization)?</P>

<P>Perhaps the &#8220;synchronizes-with&#8221; terminology could be
used here.</P>

<BR><BR><BR><BR></BODY>
</HTML>
