<HTML>
<HEAD>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>
    CWG Issue 417</TITLE>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<STYLE TYPE="text/css">
  INS { text-decoration:none; font-weight:bold; background-color:#A0FFA0 }
  .INS { text-decoration:none; background-color:#D0FFD0 }
  DEL { text-decoration:line-through; background-color:#FFA0A0 }
  .DEL { text-decoration:line-through; background-color: #FFD0D0 }
  @media (prefers-color-scheme: dark) {
    HTML { background-color:#202020; color:#f0f0f0; }
    A { color:#5bc0ff; }
    A:visited { color:#c6a8ff; }
    A:hover, a:focus { color:#afd7ff; }
    INS { background-color:#033a16; color:#aff5b4; }
    .INS { background-color: #033a16; }
    DEL { background-color:#67060c; color:#ffdcd7; }
    .DEL { background-color:#67060c; }
  }
  SPAN.cmnt { font-family:Times; font-style:italic }
</STYLE>
</HEAD>
<BODY>
<P><EM>This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21
  Core Issues List revision 118b.
  See http://www.open-std.org/jtc1/sc22/wg21/ for the official
  list.</EM></P>
<P>2025-09-28</P>
<HR>
<A NAME="417"></A><H4>417.
  
Using derived-class qualified name in out-of-class nested class definition
</H4>
<B>Section: </B>11.3&#160; [<A href="https://wg21.link/class.name">class.name</A>]
 &#160;&#160;&#160;

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

 <B>Submitter: </B>Jon Caves
 &#160;&#160;&#160;

 <B>Date: </B>19 May 2003<BR>


<P>[Voted into WP at October 2004 meeting.]</P>

<P>We had a user complain that our compiler was allowing the
following code:</P>
<PRE>
  struct B {
    struct S;
  };

  struct D : B { };

  struct D::S {
  };
</PRE>

<P>We took one look at the code and made the reasonable (I would claim)
assumption that this was
indeed a bug in our compiler. Especially as we had just fixed a very
similar issue with the
definition of static data members.</P>

<P>Imagine our surprise when code like this showed up in Boost and that
every other compiler we tested accepts this code. So is this
indeed legal (it seems like
it must be) and if so is there any justification for this beyond
6.5.5.2 [<A href="https://wg21.link/class.qual">class.qual</A>]?</P>

<P>
<U>John Spicer:</U>
The equivalent case for a member function is covered by the declarator
rules in 9.3.4 [<A href="https://wg21.link/dcl.meaning#1">dcl.meaning</A>] paragraph 1.  The committee has
previously run into cases where a restriction should apply to both
classes and non-classes, but fails to do so because there is no
equivalent of 9.3.4 [<A href="https://wg21.link/dcl.meaning#1">dcl.meaning</A>] paragraph 1 for classes.</P>

<P>Given that, by the letter of the standard, I would say that this
case is allowed.</P>

<P><B>Notes from October 2003 meeting:</B></P>

<P>We feel this case should get an error.</P>

<P><B>Proposed Resolution (October 2003):</B></P>

<P>Note that the change here interacts with
<A HREF="432.html">issue 432</A>.</P>

<P>Add the following as a new paragraph immediately following
6.4.2 [<A href="https://wg21.link/basic.scope.pdecl#2">basic.scope.pdecl</A>] paragraph 2:</P>
<BLOCKQUOTE>
The point of declaration for a class first declared by a
<I>class-specifier</I> is
immediately after the <I>identifier</I>
or <I>template-id</I> (if any) in its <I>class-head</I>
(Clause 11 [<A href="https://wg21.link/class">class</A>]).
The point of declaration for an enumeration is immediately after
the <I>identifier</I> (if any) in its <I>enum-specifier</I>
(9.8.1 [<A href="https://wg21.link/dcl.enum">dcl.enum</A>]).
</BLOCKQUOTE>

<P>Change point 1 of 6.4.7 [<A href="https://wg21.link/basic.scope.class#1">basic.scope.class</A>] paragraph 1 to read: </P>
<BLOCKQUOTE>
The potential scope of a name declared in a class consists not only of the
declarative region following the name's
<DEL>declarator</DEL> <INS>point of declaration</INS>, but also
of all function bodies, default arguments, and constructor
<I>ctor-initializer</I>s in that
class (including such things in nested classes).
</BLOCKQUOTE>

<P><I>[Note that the preceding change duplicates one of the changes
in the proposed resolution of issue 432.]</I></P>

<P>Change 13.9.3 [<A href="https://wg21.link/temp.explicit#2">temp.explicit</A>] paragraph 2 to read: </P>
<BLOCKQUOTE>
If the explicit instantiation is for a member function, a member
class or a static
data member of a class template specialization, the name of
the class template
specialization in the <I>qualified-id</I> for the member <DEL>declarator</DEL>
<INS>name</INS> shall be a <I>template-id</I>.
</BLOCKQUOTE>

<P>Add the following as paragraph 5 of Clause 11 [<A href="https://wg21.link/class">class</A>]:</P>
<BLOCKQUOTE>
If a <I>class-head</I> contains a <I>nested-name-specifier</I>,
the <I>class-specifier</I> shall refer to a
class that was previously declared directly in the class or namespace
to which the <I>nested-name-specifier</I> refers (i.e., neither
inherited nor introduced by a <I>using-declaration</I>),
and the <I>class-specifier</I> shall appear in a namespace enclosing the
previous declaration.
</BLOCKQUOTE>

<P>Delete 11.3 [<A href="https://wg21.link/class.name#4">class.name</A>] paragraph 4 (this was added
by <A HREF="284.html">issue 284</A>):</P>
<BLOCKQUOTE>
When a <I>nested-name-specifier</I> is specified in a
<I>class-head</I> or in an
<I>elaborated-type-specifier</I>, the resulting qualified name
shall refer to a previously declared member of the class or namespace to
which the <I>nested-name-specifier</I> refers, and
the member shall not have been introduced by a
using-declaration in the scope of the class or namespace
nominated by the <I>nested-name-specifier</I>.
</BLOCKQUOTE>

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