<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;P0575R0</TD>
</TR>
<TR>
<TD ALIGN="RIGHT">
      Date:
     </TD>
<TD>
      &#160;2017-02-06</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, 2016 (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="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>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):</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>

<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="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="2191"></A><H4>2191.
  
Incorrect result for <TT>noexcept(typeid(v))</TT>
</H4><B>Section: </B>15.4&#160; [except.spec]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Mike Miller
 &#160;&#160;&#160;

 <B>Date: </B>2015-10-26


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

<PRE>
    struct B { virtual void f() { } };
    struct D : B { } d;
    bool b = noexcept(typeid(d));
</PRE>

<P>According to 5.3.7 [expr.unary.noexcept] paragraph 3, the value of
<TT>b</TT> should be <TT>false</TT>, because 15.4 [except.spec]
bullet 14.6 says,</P>

<UL><LI>

<P>If <TT>e</TT> is a <TT>typeid</TT> expression applied to a glvalue
expression whose type is a polymorphic class type
(5.2.8 [expr.typeid]), <I>S</I> consists of the type
<TT>std::bad_typeid</TT>.</P></LI>

</UL>

<P>and <TT>d</TT> is such an expression. This is clearly bogus, as the
expression cannot possibly throw; according to 5.2.8 [expr.typeid]
paragraph 2, the condition under which the exception might be thrown
is:</P>

<BLOCKQUOTE>

If the glvalue expression is obtained by applying the unary <TT>*</TT>
operator to a pointer<SUP>69</SUP> and the pointer is a null pointer value
(4.11 [conv.ptr]), the <TT>typeid</TT> expression throws an exception
(15.1 [except.throw]) of a type that would match a handler of type
<TT>std::bad_typeid</TT> exception (18.7.4 [bad.typeid]).

</BLOCKQUOTE>

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

<P>Change 15.4 [except.spec] bullet 13.6 as follows:</P>

<BLOCKQUOTE>

<P>The <I>set of potential exceptions of an expression</I>
<TT>e</TT> is empty if <TT>e</TT> is a core constant expression
(5.20 [expr.const]). Otherwise, it is the union of the sets of
potential exceptions of the immediate subexpressions of <TT>e</TT>,
including default argument expressions used in a function call, combined
with a set <I>S</I> defined by the form of <TT>e</TT>, as follows:</P>

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

<LI><P>If <TT>e</TT> is a <TT>typeid</TT> expression applied to
a <SPAN style="text-decoration:line-through;background-color:#FFA0A0">glvalue expression whose type is</SPAN> <SPAN style="font-weight:bold;background-color:#A0FFA0">(possibly parenthesized)
built-in unary <TT>*</TT> operator applied to a pointer to</SPAN> a
polymorphic class type (5.2.8 [expr.typeid]), <I>S</I> consists of
the type <TT>std::bad_typeid</TT>. [<I>Example:</I> ...</P></LI>

</UL>

</BLOCKQUOTE>

<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></BODY>
</HTML>
