<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;P0622R0</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>
     Additional Core Language Working Group "ready" and "tentatively ready" Issues
     for the
     February, 2017 (Kona) meeting
    </H2>
</CENTER><BR><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="1622"></A><H4>1622.
  
Empty aggregate initializer for union
</H4><B>Section: </B>8.6.1&#160; [dcl.init.aggr]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Daveed Vandevoorde
 &#160;&#160;&#160;

 <B>Date: </B>2013-02-14


<P>According to 8.6.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.6.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 issue 1460.)</P>

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

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

<BLOCKQUOTE>

<P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">If there are fewer <I>initializer-clause</I>s in the list than there are
elements in the aggregate, then each</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">Each non-variant</SPAN>
element <SPAN style="font-weight:bold;background-color:#A0FFA0">of the aggregate that is</SPAN>
not explicitly initialized
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">shall be</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is</SPAN>
initialized from its default member initializer
(9.2 [class.mem]) or, if there is no default member initializer,
<SPAN style="font-weight:bold;background-color:#A0FFA0">copy-initialized</SPAN>
from an empty initializer list
(8.6.4 [dcl.init.list]). <SPAN style="font-weight:bold;background-color:#A0FFA0">If the aggregate is a union
and the initializer list is empty, then</SPAN></P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if any union member has a default member initilizer, that
member is initialized from its default member initializer;</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">otherwise, the first member of the union (if any) is
copy-initialized from an empty initializer list.</SPAN></P></LI>

</UL>

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

</BLOCKQUOTE>

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

<P>The resolution of issue 2272 also resolves
this issue.</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>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="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><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="2211"></A><H4>2211.
  
Hiding by lambda captures and parameters
</H4><B>Section: </B>5.1.5&#160; [expr.prim.lambda]
 &#160;&#160;&#160;

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

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

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

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

<OL><LI><P>Add the following as a new paragraph after
5.1.5 [expr.prim.lambda] paragraph 11:</P></LI>

<BLOCKQUOTE>

<P>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 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> (when the <I>simple-capture</I> is &#8220;<TT>this</TT>
&#8221; or &#8220;<TT>* this</TT> &#8221;) or a variable with automatic
storage duration declared in the reaching scope of the local lambda
expression.</P>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">If an <I>identifier</I> in a <I>simple-capture</I> appears as the
<I>declarator-id</I> of a parameter of the <I>lambda-declarator</I>'s
<I>parameter-declaration-clause</I>, the program is ill-formed.
[<I>Example:</I></SPAN></P>

<PRE>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  void f() {
    int x = 0;
    auto g = [x](int x) { return 0; }  //<SPAN style="font-family:Times;font-style:italic"> error: parameter and simple-capture have the same name</SPAN>
  }</SPAN>
</PRE>

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

</BLOCKQUOTE>

<LI><P>Change the example of 5.1.5 [expr.prim.lambda] paragraph 12
as follows:</P></LI>

<PRE>
  int x = 4;
  auto y = [&amp;r = x, x = x+1]()-&gt;int {
                  r += 2;
                  return x+2;
               }(); //<SPAN style="font-family:Times;font-style:italic"> Updates </SPAN>::x<SPAN style="font-family:Times;font-style:italic"> to 6, and initializes </SPAN>y<SPAN style="font-family:Times;font-style:italic"> to 7.</SPAN>
<SPAN style="font-weight:bold;background-color:#A0FFA0">  auto z = [a = 42](int a) { return 1; } //<SPAN style="font-family:Times;font-style:italic"> error: parameter and local variable have the same name</SPAN></SPAN>
</PRE>

</OL>

<BR><BR><HR><A NAME="2247"></A><H4>2247.
  
Lambda capture and variable argument list
</H4><B>Section: </B>5.1.5&#160; [expr.prim.lambda]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Aaron Ballman
 &#160;&#160;&#160;

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




<P><B>Notes from the December, 2016 teleconference:</B>
</P>

<P>Such examples should have undefined behavior; <TT>va_start</TT>
should only be permitted to access the arguments for the current
function.
</P>

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

<P>Change 18.10.1 [cstdarg.syn] paragraph 1 as follows:</P>

<BLOCKQUOTE>

The contents of the header <TT>&lt;cstdarg&gt;</TT> are the same as the C
standard library header <TT>&lt;stdarg.h&gt;</TT>, with the following
changes: The restrictions that ISO C places on the second parameter to
the <TT>va_start()</TT> macro in header <TT>&lt;stdarg.h&gt;</TT> are
different in this International Standard. The parameter <TT>parmN</TT> is
<SPAN style="text-decoration:line-through;background-color:#FFA0A0">the identifier of</SPAN> the rightmost parameter in the variable
parameter list of the function definition (the one just before
the <TT>...</TT> ).<SUP>223</SUP> <SPAN style="font-weight:bold;background-color:#A0FFA0">If the parameter
<TT>parmN</TT> is a pack expansion (14.5.3 [temp.variadic]) or an
entity resulting from a lambda capture (5.1.5 [expr.prim.lambda]), the
program is ill-formed, no diagnostic required.</SPAN> If the
parameter <TT>parmN</TT> is of a reference type, or of a type that is not
compatible with the type that results when passing an argument for which
there is no parameter, the behavior is undefined.

</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><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><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><HR><A NAME="2268"></A><H4>2268.
  
Unions with mutable members in constant expressions revisited
</H4><B>Section: </B>7.1.5&#160; [dcl.constexpr]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-05-26




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

<OL><LI><P>Add the following as a new bullet following
5.20 [expr.const] bullet 2.8</P></LI>

<BLOCKQUOTE>

<P>A <I>conditional-expression</I> <TT>e</TT> is a <I>core constant
expression</I> 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>an lvalue-to-rvalue conversion (4.1 [conv.lval]) that is
applied to a glvalue that refers to a non-active member of a union or a
subobject thereof;</P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">an invocation of an implicitly-defined copy/move constructor
or copy/move assignment operator for a union whose active member (if any)
is mutable, unless the lifetime of the union object begain within the
evaluation of <TT>e</TT>;</SPAN></P></LI>

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

</UL>

</BLOCKQUOTE>

<LI><P>Delete bullet 3.2 in 7.1.5 [dcl.constexpr]:</P></LI>

<UL><LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">for a defaulted copy/move assignment, the class of which it
is a member shall not have a mutable subobject that is a variant
member;</SPAN></P></LI>

</UL>

<LI><P>Delete bullet 4.2 in 7.1.5 [dcl.constexpr]:</P></LI>

<UL><LI><P><SPAN style="text-decoration:line-through;background-color:#FFA0A0">for a defaulted copy/move constructor, the class shall not
have a mutable subobject that is a variant member;</SPAN></P></LI>
</UL>

</OL>

<BR><BR><HR><A NAME="2272"></A><H4>2272.
  
Implicit initialization of aggregate members of reference type
</H4><B>Section: </B>8.6.1&#160; [dcl.init.aggr]
 &#160;&#160;&#160;

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

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

 <B>Date: </B>2016-06-10




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

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

<BLOCKQUOTE>

<P>If there are fewer <I>initializer-clause</I>s in the list than there are
elements in <SPAN style="text-decoration:line-through;background-color:#FFA0A0">the</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">a non-union</SPAN> aggregate, then each
element not explicitly initialized <SPAN style="text-decoration:line-through;background-color:#FFA0A0">shall be initialized from its default
member initializer (9.2 [class.mem]) or, if there is no default
member initializer, from an empty initializer list
(8.6.4 [dcl.init.list]).</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">is initialized as follows:</SPAN>
</P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">If the element has a default member initializer
(9.2 [class.mem]), the element is initialized from that
initializer.</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">Otherwise, if the element is not a reference, the element is
copy-initialized from an empty initializer list
(8.6.4 [dcl.init.list]).</SPAN></P></LI>

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

</UL>

<P><SPAN style="font-weight:bold;background-color:#A0FFA0">If the aggregate is a union and the initializer list is empty,
then</SPAN></P>

<UL><LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">if any variant member has a default member initializer,
that member is initialized from its default member
initializer;</SPAN></P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">otherwise, the first member of the union (if any) is
copy-initialized from an empty initializer list.</SPAN></P></LI>

</UL>

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

</BLOCKQUOTE>

<LI><P>Delete 8.6.1 [dcl.init.aggr] paragraph 11:</P></LI>

<BLOCKQUOTE>

<SPAN style="text-decoration:line-through;background-color:#FFA0A0">If an incomplete or empty <I>initializer-list</I> leaves a member of
reference type uninitialized, the program is ill-formed.</SPAN>

</BLOCKQUOTE>

</OL>

<P>This resolution also resolves issue 1622.</P>

<BR><BR><HR><A NAME="2276"></A><H4>2276.
  
Dependent <TT>noexcept</TT> and function type-dependence
</H4><B>Section: </B>14.6.2.3&#160; [temp.dep.constexpr]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Maxim Kartashev
 &#160;&#160;&#160;

 <B>Date: </B>2016-06-23




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

<P>Add the following as a new bullet following
14.6.2.1 [temp.dep.type] bullet 9.6:</P>

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

<LI><P>an array type whose element type is dependent or whose bound (if
any) is value-dependent,</P></LI>

<LI><P><SPAN style="font-weight:bold;background-color:#A0FFA0">a function type whose exception specification is
value-dependent,</SPAN></P></LI>

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

</UL>

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