<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>
    Core "ready" Issues
   </TITLE>
</HEAD>
<BODY>
<TABLE ALIGN="RIGHT" CELLSPACING="0" CELLPADDING="0">
<TR>
<TD ALIGN="RIGHT">
      Document number:
     </TD>
<TD>
       &#160;P0575R1</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD>
<TD>
      &#160;2017-03-03</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:2014
     </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>
     Core Language Working Group "ready" Issues
     for the
     February, 2017 (Kona) meeting
    </H2>
</CENTER><BR>

<P><B>History:</B></P>

<P><B>Revision 1:</B> Issue 1622 was removed because its resolution
was modified since the pre-meeting mailing. Issue 2191 was removed
because its resolution was already applied to the working paper as
part of paper P0003R5.</P>

<P>
    Section references in this document reflect the section numbering
    of document
    <A HREF="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4606.pdf">WG21 N4606</A>.
   </P>
<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>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Steve Adamczyk
 &#160;&#160;&#160;

 <B>Date: </B>2 July 2003


<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) [SUPERSEDED]:</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 from 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>

<P><B>Proposed resolution (November, 2016):</B></P>

<P>Change 3.5 [basic.link] paragraph 6 as follows:</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
program is ill-formed.</SPAN> [<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 style="font-weight:bold;background-color:#A0FFA0">:</SPAN> </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 style="font-weight:bold;background-color:#A0FFA0">, ill-formed</SPAN></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 #1 ), the object with automatic storage duration and no linkage
introduced by the declaration on line #2, and the object with static
storage duration and external linkage introduced by the declaration on line
#3.</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0"> Without the declaration at line #2, the declaration at line
#3 would link with the declaration at line #1. Because the declaration with
internal linkage is hidden, however, #3 is given external linkage, making
the program ill-formed.</SPAN> &#8212;<I>end example</I>]</P>

</BLOCKQUOTE>

<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>ready
 &#160;&#160;&#160;

 <B>Submitter: </B>Faisal Vali
 &#160;&#160;&#160;

 <B>Date: </B>5 October, 2008


<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>

<P><B>Additional note, November, 2014:</B></P>

<P>See also paper N4090.</P>

<P><B>Proposed resolution (March, 2017):</B></P>

<OL><LI><P>Change 14.5.5 [temp.class.spec] paragraph 5 as follows:</P></LI>

<BLOCKQUOTE>

<P>A class template partial specialization may be declared <SPAN style="text-decoration:line-through;background-color:#FFA0A0">or
redeclared</SPAN> in any <SPAN style="text-decoration:line-through;background-color:#FFA0A0">namespace</SPAN> scope in which the
corresponding primary template may be defined (7.3.1.2 [namespace.memdef]
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">and</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0"></SPAN>, 9.2 [class.mem],
14.5.2 [temp.mem]). [<I>Example:</I></P>

<PRE>
  template&lt;class T&gt; struct A {
    struct C {
      template&lt;class T2&gt; struct B { };
<SPAN style="font-weight:bold;background-color:#A0FFA0">      template&lt;class T2&gt; struct B&lt;T2**&gt; { };  //<SPAN style="font-family:Times;font-style:italic"> partial specialization #1</SPAN></SPAN>
    };
  };

  //<SPAN style="font-family:Times;font-style:italic"> partial specialization of </SPAN>A&lt;T&gt;::C::B&lt;T2&gt;
  template&lt;class T&gt; template&lt;class T2&gt;
    struct A&lt;T&gt;::C::B&lt;T2*&gt; { };    <SPAN style="font-weight:bold;background-color:#A0FFA0">//<SPAN style="font-family:Times;font-style:italic"> #2</SPAN>
</SPAN>

  A&lt;short&gt;::C::B&lt;int*&gt; absip; //<SPAN style="font-family:Times;font-style:italic"> uses partial specialization <SPAN style="font-weight:bold;background-color:#A0FFA0">#2</SPAN>
</SPAN>
</PRE>

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

</BLOCKQUOTE>

<LI><P>Change 14.7.3 [temp.expl.spec] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

An explicit specialization <SPAN style="text-decoration:line-through;background-color:#FFA0A0">shall be declared in a namespace enclosing the
specialized template. An explicit specialization whose <I>declarator-id</I>
or <I>class-head-name</I> is not qualified shall be declared in the nearest
enclosing namespace of the template, or, if the namespace is inline
(7.3.1 [namespace.def]), any namespace from its enclosing namespace
set. Such a declaration may also be a definition</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">may be declared in any scope in which the corresponding primary
template may be defined (7.3.1.2 [namespace.memdef],
9.2 [class.mem], 14.5.2 [temp.mem])</SPAN>. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">If the
declaration is not a definition, the specialization may be defined later
(7.3.1.2 [namespace.memdef]).</SPAN>

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1677"></A><H4>1677.
  
Constant initialization via aggregate initialization
</H4><B>Section: </B>3.6.2&#160; [basic.start.static]
 &#160;&#160;&#160;

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

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

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




<P>The resolution of issue 1489 added wording
regarding value initialization to 3.6.2 [basic.start.static] 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>

<P><B>Proposed resolution (November, 2017):</B></P>

<OL><LI><P>Change 3.6.2 [basic.start.static] paragraph 2 as follows,
converting the bulleted list into running text as indicated:</P></LI>

<BLOCKQUOTE>

<P>A <I>constant initializer</I> for <SPAN style="text-decoration:line-through;background-color:#FFA0A0">an</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a variable or
temporary</SPAN> object <TT>o</TT> is an <SPAN style="text-decoration:line-through;background-color:#FFA0A0">expression
that</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">initializer whose full-expression</SPAN> is a constant
expression, except that <SPAN style="text-decoration:line-through;background-color:#FFA0A0">it</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">if <TT>o</TT> is an object, such
an initializer</SPAN> 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>] <I>Constant initialization</I> is
performed<SPAN style="text-decoration:line-through;background-color:#FFA0A0">:</SPAN>
</P>

<UL><LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">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.20 [expr.const]) and the
reference is bound to a glvalue designating an object with static storage
duration, to a temporary object (see 12.2 [class.temporary]) or
subobject thereof, or to a function;</SPAN></P></LI>

<LI><P>if <SPAN style="text-decoration:line-through;background-color:#FFA0A0">an</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a variable or temporary</SPAN> object with
static or thread storage duration is initialized by a <SPAN style="text-decoration:line-through;background-color:#FFA0A0">constructor
call, and if the initialization full-expression is a</SPAN> constant
initializer for the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">object;</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">entity</SPAN></P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">if an object with static or thread storage duration is not
initialized by a constructor call and if either the object is
value-initialized or every full-expression that appears in its initializer
is a constant expression</SPAN>.</P></LI>

</UL>

<P>If constant initialization is not performed...</P>

</BLOCKQUOTE>

<LI><P>Change 5.20 [expr.const] paragraph 2 as follows:</P>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">A <I>conditional-expression</I></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">An expression</SPAN>
<TT>e</TT> is a <I>core constant expression</I> unless...

</BLOCKQUOTE>
</LI>

</OL>

<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>ready
 &#160;&#160;&#160;

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

 <B>Date: </B>2013-07-03


<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>

<P><B>Additional note (January, 2014):</B></P>

<P>This is effectively issues 314 and
343.</P>

<P>See also issue 1812.</P>

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

<OL><LI><P>Change 9 [class] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

If a class is marked with the <I>class-virt-specifier</I> <TT>final</TT>
and it appears as
a <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>base-type-specifier</I></SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0"><I>class-or-decltype</I></SPAN>
in a <I>base-clause</I> (Clause 10 [class.derived]), the program is
ill-formed. Whenever a <I>class-key</I> is followed...

</BLOCKQUOTE>

<LI><P>Change the grammar in 10 [class.derived] paragraph 1 as
follows:</P></LI>

<UL><I>base-specifier:</I>
<UL><I>attribute-specifier-seq<SUB>opt</SUB> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">base-type-specifier</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">class-or-decltype</SPAN></I><BR>
<I>attribute-specifier-seq<SUB>opt</SUB></I> <TT>virtual</TT> <I>access-specifier<SUB>opt</SUB> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">base-type-specifier</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">class-or-decltype</SPAN></I><BR>
<I>attribute-specifier-seq<SUB>opt</SUB> access-specifier</I> <TT>virtual</TT><I><SUB>opt</SUB> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">base-type-specifier</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">class-or-decltype</SPAN></I>
</UL>
<I>class-or-decltype:</I>
<UL><I>nested-name-specifier<SUB>opt</SUB> class-name</I><BR>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>nested-name-specifier</I> <TT>template</TT> <I>simple-template-id</I></SPAN><BR>
<I>decltype-specifier</I>
</UL>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>base-type-specifier:</I></SPAN>
<UL><SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>class-or-decltype</I></SPAN>
</UL>
<I>access-specifier:</I>
<UL>...</UL>
</UL>

<LI><P>Delete paragraph 4 and change paragraph 5 of
14.2 [temp.names] as follows, splitting paragraph 5 into two
paragraphs and moving the example from paragraph 4 into paragraph
5:</P></LI>

<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">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>.  Otherwise the name is assumed to name a
non-template. [<I>Example:</I> ... &#8212;<I>end example</I>]</SPAN></P>

<P>A name prefixed by the keyword <TT>template</TT> shall be
a <I>template-id</I> or the name shall refer to a class template
<SPAN style="font-weight:bold;background-color:#A0FFA0">or alias template</SPAN>.  [<I>Note:</I> The keyword <TT>template</TT>
may not be applied to non-template members of class
templates. &#8212;<I>end note</I>] <SPAN style="font-weight:bold;background-color:#A0FFA0">The <I>nested-name-specifier</I>
(_N4567_.5.1.1 [expr.prim.general]) of</SPAN></P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">a <I>class-head-name</I> (Clause 9 [class])
or <I>enum-head</I> (7.2 [dcl.enum]) (if any) or</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">a <I>qualified-id</I> in a <I>declarator-id</I>
(Clause 8 [dcl.decl]),</SPAN></P></LI>

</UL>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">or a <I>nested-name-specifier</I> directly contained in such a
<I>nested-name-specifier</I> (recursively), shall not be of the form</SPAN></P>

<UL><SPAN style="font-weight:bold;background-color:#A0FFA0"><I>nested-name-specifier</I> <TT>template</TT> <I>simple-template-id</I> <TT>::</TT></SPAN></UL>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I> That is, a <I>simple-template-id</I> shall not be
prefixed by the keyword <TT>template</TT> in these cases. &#8212;<I>end
note</I>]</SPAN></P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">The keyword <TT>template</TT> is optional in a
<I>typename-specifier</I> (14.6 [temp.res]),
<I>elaborated-type-specifier</I> (7.1.7.3 [dcl.type.elab]),
<I>using-declaration</I> (7.3.3 [namespace.udecl]), or
<I>class-or-decltype</I> (Clause 10 [class.derived]), and in
recursively directly-contained <I>nested-name-specifier</I>s thereof.
In these contexts, a <TT>&lt;</TT> token is always assumed to introduce
a <I>template-argument-list</I>. [<I>Note:</I> Thus, if the preceding
name is not a <I>template-name</I>, the program is ill-formed.
&#8212;<I>end note</I>] In other contexts, when the name of a member
template specialization appears after a <I>nested-name-specifier</I> that
denotes a dependent type, but the name is not a member of the current
instantiation, the member template name shall be prefixed by the
keyword <TT>template</TT>.  Similarly, when the name of a member
template specialization appears after <TT>.</TT> or <TT>-&gt;</TT>
in a <I>postfix-expression</I> (5.2 [expr.post]) and the
object expression of the <I>postfix-expression</I> is type-dependent,
but the name is not a member of the current instantiation
(14.6.2.1 [temp.dep.type]), the member template name shall be
prefixed by the keyword <TT>template</TT>. Otherwise, the name is
assumed to name a non-template. [<I>Example:</I></SPAN></P>

<PRE>
    <I>&lt;From original paragraph 4&gt;</I>
</PRE>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">&#8212;<I>end example]</I></SPAN> [<I>Note:</I> As is the case with
the <TT>typename</TT> prefix...</P>

</BLOCKQUOTE>

</OL>

<P>This resolution also resolves issues 314,
343, 1794, and
1812.</P>

<P><B>Additional note, November, 2014:</B></P>

<P>Concerns have been expressed over the clarity and organization of
the proposed resolution, so the issue has been moved back to "review"
status to allow CWG to address these concerns.</P>

<P><B>Proposed resolution, March, 2017:</B></P>

<OL><LI><P>Change 9 [class] paragraph 3 as follows:</P></LI>

<BLOCKQUOTE>

If a class is marked with the <I>class-virt-specifier</I> <TT>final</TT>
and it appears as a <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>base-type-specifier</I></SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>class-or-decltype</I></SPAN> in a <I>base-clause</I> (Clause
10 [class.derived]), the program is ill-formed. Whenever
a <I>class-key</I> is followed by a <I>class-head-name</I>...

</BLOCKQUOTE>

<LI><P>Change the grammar in 10 [class.derived] paragraph 1 as
follows:</P></LI>

<UL><I>base-specifier:</I>
<UL><I>attribute-specifier-seq<SUB>opt</SUB> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">base-type-specifier</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">class-or-decltype</SPAN></I><BR>
<I>attribute-specifier-seq<SUB>opt</SUB></I> <TT>virtual</TT> <I>access-specifier<SUB>opt</SUB> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">base-type-specifier</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">class-or-decltype</SPAN></I><BR>
<I>attribute-specifier-seq<SUB>opt</SUB> access-specifier</I> <TT>virtual</TT><I><SUB>opt</SUB> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">base-type-specifier</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">class-or-decltype</SPAN></I>
</UL><BR>
<I>class-or-decltype:</I>
<UL><I>nested-name-specifier<SUB>opt</SUB> class-name</I><BR>
<SPAN style="font-weight:bold;background-color:#A0FFA0"><I>nested-name-specifier</I> <TT>template</TT> <I>simple-template-id</I><BR></SPAN>
<I>decltype-specifier</I>
</UL><BR>
<SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>base-type-specifier:</I></SPAN>
<UL><SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>class-or-decltype</I></SPAN>
</UL>
</UL>

<LI><P>Change 10 [class.derived] paragraph 2 as followx:</P></LI>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">The type denoted by a <I>base-type-specifier</I></SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">A <I>class-or-decltype</I></SPAN> shall <SPAN style="text-decoration:line-through;background-color:#FFA0A0">be</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">denote</SPAN> a class type that is not an incompletely defined class
(Clause 9 [class])<SPAN style="text-decoration:line-through;background-color:#FFA0A0">; this</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0">. The</SPAN>
class <SPAN style="font-weight:bold;background-color:#A0FFA0">denoted by the <I>class-or-decltype</I> of
a <I>base-specifier</I></SPAN> is called a <I>direct base class</I> for the
class being defined. During the lookup for a base class name...

</BLOCKQUOTE>

<LI><P>Change 14.2 [temp.names] paragraphs 4 and 5 as
follows:</P></LI>

<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">When the name of a member template specialization appears after
. or -&gt; 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</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">The keyword <TT>template</TT> is said to appear
at the top level in a <I>qualified-id</I> if it appears outside of a
<I>template-argument-list</I> or <I>decltype-specifier</I>. In a
<I>qualified-id</I> of a <I>declarator-id</I> or in a
<I>qualified-id</I> formed by a <I>class-head-name</I> (Clause
9 [class]) or <I>enum-head-name</I> (7.2 [dcl.enum]),
the keyword <TT>template</TT> shall not appear at the top level. In a
<I>qualified-id</I> used as the name in a <I>typename-specifier</I>
(14.6 [temp.res]), <I>elaborated-type-specifier</I>
(7.1.7.3 [dcl.type.elab]), <I>using-declaration</I>
(7.3.3 [namespace.udecl]), or <I>class-or-decltype</I> (Clause
10 [class.derived]), an optional keyword <TT>template</TT> appearing
at the top level is ignored. In these contexts, a <TT>&lt;</TT> token is
always assumed to introduce a <I>template-argument-list</I>. In all other
contexts, when naming a template specialization of a member of an unknown
specialization</SPAN> (14.6.2.1 [temp.dep.type]), the member template
name <SPAN style="text-decoration:line-through;background-color:#FFA0A0">must</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">shall</SPAN> be prefixed by the
keyword <TT>template</TT>. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">Otherwise the name is assumed to name a
non-template.</SPAN> [<I>Example:</I>...</P>

<P>A name prefixed by the keyword <TT>template</TT> shall be
a <I>template-id</I> or the name shall refer to a class template <SPAN style="font-weight:bold;background-color:#A0FFA0">or an
alias template</SPAN>.  [<I>Note:</I> The keyword <TT>template</TT> may not
be applied to non-template members of class templates. &#8212;<I>end
note</I>]...</P>

</BLOCKQUOTE>

<LI><P>Change 14.6 [temp.res] paragraph 5 as follows:</P></LI>

<BLOCKQUOTE>

A qualified name used as the name in a <SPAN style="text-decoration:line-through;background-color:#FFA0A0"><I>mem-initializer-id</I>,
a <I>base-specifier</I>,</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0"><I>class-or-decltype</I> (Clause
10 [class.derived])</SPAN> or an <I>elaborated-type-specifier</I> is
implicitly assumed to name a type, without the use of the <TT>typename</TT>
keyword. In a <I>nested-name-specifier</I> that immediately contains
a <I>nested-name-specifier</I> that depends on a template parameter, the
identifier or <I>simple-template-id</I> is implicitly assumed to name a
type, without the use of the <TT>typename</TT> keyword. [<I>Note:</I> The
<TT>typename</TT> keyword is not permitted by the syntax of these
constructs. &#8212;<I>end note</I>]

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="1860"></A><H4>1860.
  
What is a &#8220;direct member?&#8221;
</H4><B>Section: </B>9.3&#160; [class.union]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Dawn Perchik
 &#160;&#160;&#160;

 <B>Date: </B>2014-02-13


<P>The term &#8220;direct member&#8221; is used in 9.3 [class.union]
paragraph 8 but is not defined.  It might be better to refer to the class's
<I>member-specification</I> instead.</P>

<P><B>Additional note, October, 2015:</B></P>

<P>This issue is expected to be addressed by the wording of N4532 or
a successor thereof (&#8220;Default Comparisons&#8221;).</P>

<P><B>Proposed resolution (November, 2016):</B></P>

<OL><LI><P>Change 8.6.1 [dcl.init.aggr] paragraph 2 as follows:</P></LI>

<BLOCKQUOTE>

<P>The <I>elements</I> of an aggregate are:</P>

<UL><LI><P>for an array, the array elements in increasing
subscript order, or</P></LI>

<LI><P>for a class, the direct base classes in declaration order
followed by the direct <SPAN style="font-weight:bold;background-color:#A0FFA0">non-static data</SPAN>
members <SPAN style="font-weight:bold;background-color:#A0FFA0">that are not members of an anonymous union,</SPAN>
in declaration order.</P></LI>

</UL>

</BLOCKQUOTE>

<LI><P>Change 9.2 [class.mem] paragraph 1 as follows:</P>
</LI>

<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. <SPAN style="font-weight:bold;background-color:#A0FFA0">A
<I>direct member</I> of a class <TT>X</TT> is a member of <TT>X</TT>
that was first declared within the <I>member-specification</I> of
<TT>X</TT>, including anonymous union objects and direct
members thereof.</SPAN> Members of a class are...

</BLOCKQUOTE>

<LI><P>Change 9.3.1 [class.union.anon] paragraph 1 as follows:</P>
</LI>

<BLOCKQUOTE>

<P>A union of the form</P>

<UL><TT>union {</TT> <I>member-specification</I> <TT>} ;</TT></UL>

<P>is called an <I>anonymous union</I>; it defines an
unnamed <SPAN style="font-weight:bold;background-color:#A0FFA0">type and an unnamed</SPAN> object of <SPAN style="text-decoration:line-through;background-color:#FFA0A0">unnamed</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">that</SPAN> type <SPAN style="font-weight:bold;background-color:#A0FFA0">called an <I>anonymous union
object</I></SPAN>. Each <I>member-declaration</I> in
the <I>member-specification</I> of an anonymous union</P>...

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="2174"></A><H4>2174.
  
Unclear rules for friend definitions in templates
</H4><B>Section: </B>14.5.4&#160; [temp.friend]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-09-17




<P>According to 14.5.4 [temp.friend] paragraph 4,</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 (3.2 [basic.def.odr]). The same
restrictions on multiple declarations and definitions that
apply to non-template function declarations and definitions
also apply to these implicit definitions.

</BLOCKQUOTE>

<P>This seems to imply that:</P>

<OL><LI><P>Instantiating a class template that contains a friend
function definition instantiates the declaration, but not
the definition, of that friend function, as usual (but see
below).</P></LI>

<LI>

<P>If the function is odr-used, a definition is instantiated
for each such class template specialization whose template
had a definition.</P></LI>

<LI>

<P>If that results in multiple definitions, the program is
ill-formed as usual.</P></LI>

</OL>

<P>The intent appears to be that the instantiated friend
function declarations should be treated as if they were
definitions, but that's not clear from the wording.  This
wording is also missing similar provisions for friend
function template definitions; there is implementation
divergence on the treatment of such cases.</P>

<P>There also does not appear to be wording that says that
instantiating a class template specialization results in
the instantiation of friend functions declared/defined
therein (the relevant wording was removed from this section
by issue 329). Presumably this
should be covered in 14.7.1 [temp.inst] paragraph 1,
which also includes the following wording that could be
reused for the <TT>friend</TT> case:</P>

<BLOCKQUOTE>

However, for the purpose of determining whether an
instantiated redeclaration of a member is valid according to
9.2 [class.mem], a declaration that corresponds to
a definition in the template is considered to be a
definition.

</BLOCKQUOTE>

<P>Also, the reliance on odr-use to trigger friend instantiation
is out of date, as there are other contexts that can require
an instantiation when there is no odr-use (a <TT>constexpr</TT>
function invoked within an unevaluated operand).</P>

<P><B>Proposed resolution (October, 2015) [SUPERSEDED]:</B></P>

<OL><LI><P>Delete 14.5.4 [temp.friend] paragraph 4:</P></LI>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">When a function is defined in a friend function declaration
in a class template, the function is instantiated when the
function is odr-used (3.2 [basic.def.odr]). The same
restrictions on multiple declarations and definitions that
apply to non-template function declarations and definitions
also apply to these implicit definitions.</SPAN>

</BLOCKQUOTE>

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

<BLOCKQUOTE>

...The implicit instantiation of a class template
specialization causes the implicit instantiation of the
declarations, but not of the definitions, default arguments,
or <I>exception-specification</I>s of the class member
functions, member classes, scoped member enumerations,
static data members<SPAN style="font-weight:bold;background-color:#A0FFA0">,</SPAN> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">and</SPAN> member
templates<SPAN style="font-weight:bold;background-color:#A0FFA0">, and friends</SPAN>; and it causes the
implicit instantiation of the definitions of unscoped member
enumerations and member anonymous unions. However, for the
purpose of determining whether an instantiated redeclaration
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">of a member</SPAN> is valid according
to <SPAN style="font-weight:bold;background-color:#A0FFA0">3.2 [basic.def.odr] and</SPAN>
9.2 [class.mem], a declaration that corresponds to
a definition in the template is considered to be a
definition. [<I>Example:</I>...

</BLOCKQUOTE>

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

<BLOCKQUOTE>

Unless a function template specialization has been
explicitly instantiated or explicitly specialized, the
function template specialization is implicitly instantiated
when the specialization is referenced in a context that
requires a function definition to exist. <SPAN style="font-weight:bold;background-color:#A0FFA0">A function
whose declaration was instantiated from a friend function
definition is implicitly instantiated when it is referenced
in a context that requires a function definition to
exist.</SPAN> Unless a call is to a function template
explicit specialization or to a member function of an
explicitly specialized class template, a default argument
for a function template or a member function of a class
template is implicitly instantiated when the function is
called in a context that requires the value of the default
argument.

</BLOCKQUOTE>

</OL>

<P><B>Proposed resolution (November, 2016):</B>
</P>

<OL><LI><P>Delete 14.5.4 [temp.friend] paragraph 4:</P></LI>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">When a function is defined in a friend function declaration in a class
template, the function is instantiated when the function is odr-used
(3.2 [basic.def.odr]). The same restrictions on multiple declarations
and definitions that apply to non-template function declarations and
definitions also apply to these implicit definitions.</SPAN>

</BLOCKQUOTE>

<LI><P>Change 14.7.1 [temp.inst] paragraph 1 as follows,
splitting it into two paragraphs as indicated:</P></LI>

<BLOCKQUOTE>

<P>... [<I>Note:</I> Within a template declaration, a local class
(9.4 [class.local]) 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>]</P>

<P>The implicit instantiation of a class template specialization causes
the implicit instantiation of the declarations, but not of the definitions,
default arguments, or <I>exception-specification</I>s of the class member
functions, member classes, scoped member enumerations, static data
members<SPAN style="font-weight:bold;background-color:#A0FFA0">,</SPAN> <SPAN style="text-decoration:line-through;background-color:#FFA0A0">and</SPAN> member templates<SPAN style="font-weight:bold;background-color:#A0FFA0">, and
friends</SPAN>; and it causes the implicit instantiation of the definitions
of unscoped member enumerations and member anonymous unions. However, for
the purpose of determining whether an instantiated redeclaration <SPAN style="text-decoration:line-through;background-color:#FFA0A0">of a
member</SPAN> is valid according to <SPAN style="font-weight:bold;background-color:#A0FFA0">3.2 [basic.def.odr] and</SPAN>
9.2 [class.mem], a declaration
that corresponds to a definition in the template is considered to be a
definition.  [<I>Example:</I></P>

<PRE>
  template&lt;class T, class U&gt;
  struct Outer {
    template&lt;class X, class Y&gt; struct Inner;
    template&lt;class Y&gt; struct Inner&lt;T, Y&gt;;     //<SPAN style="font-family:Times;font-style:italic"> #1a</SPAN>
    template&lt;class Y&gt; struct Inner&lt;T, Y&gt; { }; //<SPAN style="font-family:Times;font-style:italic"> #1b; OK: valid redeclaration of #1a</SPAN>
    template&lt;class Y&gt; struct Inner&lt;U, Y&gt; { }; //<SPAN style="font-family:Times;font-style:italic"> #2</SPAN>
  };

  Outer&lt;int, int&gt; outer; //<SPAN style="font-family:Times;font-style:italic"> error at #2</SPAN>
</PRE>

<P><TT>Outer&lt;int, int&gt;::Inner&lt;int, Y&gt;</TT> is redeclared at
#1b. (It is not defined but noted as being associated with a definition
in <TT>Outer&lt;T, U&gt;</TT>.) #2 is also a redeclaration of #1a. It is
noted as associated with a definition, so it is an invalid redeclaration of
the same partial specialization.</P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  template&lt;typename T&gt; struct Friendly {
    template&lt;typename U&gt; friend int f(U) { return sizeof(T); }
  };
  Friendly&lt;char&gt; fc;
  Friendly&lt;float&gt; ff; //<SPAN style="font-family:Times;font-style:italic"> ill-formed: produces second definition of </SPAN>f(U)</SPAN>
</PRE>

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

</BLOCKQUOTE>

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

<BLOCKQUOTE>

Unless a function template specialization has been explicitly instantiated
or explicitly specialized, the function template specialization is
implicitly instantiated when the specialization is referenced in a context
that requires a function definition to exist. <SPAN style="font-weight:bold;background-color:#A0FFA0">A function whose
declaration was instantiated from a friend function definition is
implicitly instantiated when it is referenced in a context that requires
a function definition to exist.</SPAN> Unless a call is to a function
template explicit specialization or to a member function of an explicitly
specialized class template, a default argument for a function template or a
member function of a class template is implicitly instantiated when the
function is called in a context that requires the value of the default
argument.

</BLOCKQUOTE>
</LI>

</OL>

<BR><BR><HR><A NAME="2196"></A><H4>2196.
  
Zero-initialization with virtual base classes
</H4><B>Section: </B>8.6&#160; [dcl.init]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-11-06




<P>[Detailed description pending.]</P>

<P><B>Proposed resolution (November, 2016):</B></P>

<P>Change 8.6 [dcl.init] bullet 6.2 as follows:</P>

<BLOCKQUOTE>

<P>To <I>zero-initialize</I> an object or reference of type <TT>T</TT>
means:</P>

<UL><LI><P>if <TT>T</TT> is a scalar type (3.9 [basic.types]), the
object is initialized to the value obtained by converting the integer
literal <TT>0</TT> (zero) to <TT>T</TT>;<SUP>103</SUP></P></LI>

<LI><P>if <TT>T</TT> is a (possibly cv-qualified) non-union class type,
each non-static data member<SPAN style="font-weight:bold;background-color:#A0FFA0">, each non-virtual base class
subobject,</SPAN> and<SPAN style="font-weight:bold;background-color:#A0FFA0">, if the object is not a base class
subobject,</SPAN> each <SPAN style="font-weight:bold;background-color:#A0FFA0">virtual</SPAN> base<SPAN style="text-decoration:line-through;background-color:#FFA0A0">-</SPAN><SPAN style="font-weight:bold;background-color:#A0FFA0"> </SPAN> class
subobject is zero-initialized and padding is initialized to zero
bits;</P></LI>

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

</UL>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2198"></A><H4>2198.
  
Linkage of enumerators
</H4><B>Section: </B>3.5&#160; [basic.link]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-11-12




<P>According to the rules in 3.5 [basic.link] paragraph 4,
the enumerators of an enumeration type with linkage also have linkage.
Having same-named enumerators in different translation units
would seem to be innocuous. Is there a rationale for this rule?</P>

<P><B>Proposed resolution (March, 2017):</B></P>

<OL><LI><P>Delete 3.5 [basic.link] bullet 4.5:</P></LI>

<BLOCKQUOTE>

<P>An unnamed namespace or a namespace declared directly or indirectly within
an unnamed namespace has internal linkage. All other namespaces have
external linkage. A name having namespace scope that has not been given
internal linkage above has the same linkage as the enclosing namespace if
it is the name of</P>

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

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">an enumerator belonging to an enumeration with linkage;
or</SPAN></P></LI>

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

</UL>

</BLOCKQUOTE>

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

<BLOCKQUOTE>

Two names that are the same (Clause 3 [basic]) and that are
declared in different scopes shall denote the same variable, function,
type, <SPAN style="text-decoration:line-through;background-color:#FFA0A0">enumerator,</SPAN> template or namespace if...

</BLOCKQUOTE>

</OL>

<BR><BR><HR><A NAME="2205"></A><H4>2205.
  
Restrictions on use of <TT>alignas</TT>
</H4><B>Section: </B>7.6.1&#160; [dcl.attr.grammar]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-11-30




<P>According to 7.6.1 [dcl.attr.grammar] paragraph 5, a program is
ill-formed if an <I>attribute</I> appertains to an entity or statement to
which it is not allowed to apply. Presumably an <I>alignment-specifier</I>
should have the same restriction.</P>

<P><B>Proposed resolution (November, 2016):</B></P>

<P>Change 7.6.1 [dcl.attr.grammar] paragraph 5 as follows:</P>

<BLOCKQUOTE>

Each <I>attribute-specifier-seq</I> is said to <I>appertain</I> to some
entity or statement, identified by the syntactic context where it appears
(Clause 6 [stmt.stmt], Clause 7 [dcl.dcl], Clause
8 [dcl.decl]). If an <I>attribute-specifier-seq</I> that
appertains to some entity or statement contains an <I>attribute</I>
<SPAN style="font-weight:bold;background-color:#A0FFA0">or <I>alignment-specifier</I></SPAN> that is not allowed to apply to
that entity or statement, the program is ill-formed. If
an <I>attribute-specifier-seq</I> appertains to a friend declaration
(11.3 [class.friend]), that declaration shall be a
definition. No <I>attribute-specifier-seq</I> shall appertain to an
explicit instantiation (14.7.2 [temp.explicit]).

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2218"></A><H4>2218.
  
Ambiguity and namespace aliases
</H4><B>Section: </B>3.4&#160; [basic.lookup]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2015-12-29




<P>There is implementation divergence on the status of the following
example:</P>

<PRE>
  namespace A { namespace B { int x; } }
  namespace C { namespace B = A::B; }
  using namespace A;
  using namespace C;
  int x = B::x;
</PRE>

<P>This should presumably be valid: the lookup of <TT>B</TT> finds
<TT>A::B</TT> and <TT>C::B</TT>, but it is not ambiguous because they
denote the same entity. A similar example with a <I>using-declaration</I>
or <I>alias-declaration</I> seems to be universally accepted. Perhaps
the lookup rules need to be clarified regarding the status of this
example.</P>

<P><B>Proposed resolution (November, 2016):</B></P>

<P>Change 3.4 [basic.lookup] paragraph 1 as follows:</P>

<BLOCKQUOTE>

The name lookup rules apply uniformly to all names
(including <I>typedef-name</I>s
(7.1.3 [dcl.typedef]), <I>namespace-name</I>s
(7.3 [basic.namespace]), and <I>class-name</I>s
(9.1 [class.name])) wherever the grammar allows such names in the
context discussed by a particular rule.  Name lookup associates the use of
a name with a <SPAN style="text-decoration:line-through;background-color:#FFA0A0">declaration</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">set of declarations</SPAN>
(3.1 [basic.def]) of that name. <SPAN style="text-decoration:line-through;background-color:#FFA0A0">Name lookup shall find an
unambiguous declaration for the name (see 10.2 [class.member.lookup]). Name
lookup may associate more than one declaration with a name if it finds the
name to be a function name;</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">The declarations found by name
lookup shall either all declare the same entity or shall all declare
functions; in the latter case,</SPAN> the declarations are said to form a
set of overloaded functions (13.1 [over.load]). Overload
resolution...

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2248"></A><H4>2248.
  
Problems with sized delete
</H4><B>Section: </B>5.3.5&#160; [expr.delete]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-03-14




<P>[Detailed description pending.]</P>

<P><B>Proposed resolution (December, 2016):</B>
</P>

<P>Change 5.3.5 [expr.delete] paragraph 11 as follows:</P>

<BLOCKQUOTE>

When a <I>delete-expression</I> is executed, the selected deallocation
function shall be called with the address of the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">block of storage to
be reclaimed</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">most-derived object in the <I>delete object</I>
case, or the address of the object suitably adjusted for the array
allocation overhead (5.3.4 [expr.new]) in the <I>delete array</I>
case,</SPAN> as its first argument. If a deallocation function with a
parameter of type <TT>std::align_val_t</TT> is used, the alignment of the
type of the object to be deleted is passed as the corresponding
argument. If a deallocation function with a parameter of
type <TT>std::size_t</TT> is used, the size of the <SPAN style="text-decoration:line-through;background-color:#FFA0A0">block</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">most-derived type, or of the array plus allocation overhead,
respectively,</SPAN> is passed as the corresponding argument.
<SPAN style="font-weight:bold;background-color:#A0FFA0">[<I>Note:</I> If this results in a call to a usual deallocation
function, and either the first argument was not the result of a prior
call to a usual allocation function or the second argument was not the
corresponding argument in said call, the behavior is undefined
(18.6.2.1 [new.delete.single], 18.6.2.2 [new.delete.array]).
&#8212;<I>end note</I>]</SPAN>

</BLOCKQUOTE>

<BR><BR><HR><A NAME="2251"></A><H4>2251.
  
Unreachable enumeration list-initialization
</H4><B>Section: </B>8.6.4&#160; [dcl.init.list]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-03-22




<P>[Detailed description pending.]</P>

<P><B>Proposed resolution (December, 2016):</B>
</P>

<P>Reorder the bullets in 8.6.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>...</P></LI>

<LI><P>Otherwise, if <TT>T</TT> is a class type, constructors are
considered...</P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">Otherwise, if <TT>T</TT> is an enumeration with a fixed underlying
type (7.2 [dcl.enum]), the <I>initializer-list</I> has a single
element <TT>v</TT>, and the initialization is direct-list-initialization,
the object is initialized with the value <TT>T(v)</TT>
(5.2.3 [expr.type.conv]); if a narrowing conversion is required to
convert v to the underlying type of <TT>T</TT>, the program is ill-formed.
[<I>Example:</I>...</SPAN></P></LI>

<LI><P>Otherwise, if the initializer list has a single element of
type <TT>E</TT>...</P></LI>

<LI><P>Otherwise, if <TT>T</TT> is a reference type...</P></LI>

<LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">Otherwise, if <TT>T</TT> is an enumeration with a fixed
underlying type...</SPAN>
</P></LI>

</UL>

</BLOCKQUOTE>

<BR><BR></BODY>
</HTML>
