Proposed resolution (10/00):

Add after 13.8.2 [temp.local] paragraph 2:

Within the scope of a class template, when the unqualified name of a nested class of the class template is referred to, it is equivalent to the name of the nested class qualified by the name of the enclosing class template. [Example:

    template <class T> struct A {
	class B {};
	// B is equivalent to A::B, which is equivalent to A<T>::B,
	// which is dependent.
	class C : B { };
    };

—end example]

Proposed resolution (10/00):

Add after 13.8.2 [temp.local] paragraph 2:

Within the scope of a class template, when the unqualified name of a nested class of the class template is referred to, it is equivalent to the name of the nested class qualified by the name of the enclosing class template. [Example:

    template <class T> struct A {
	class B {};
	// B is equivalent to A::B, which is equivalent to A<T>::B,
	// which is dependent.
	class C : B { };
    };

—end example]

Mark Mitchell (via John Spicer): Given:

  template <class T> struct S {
     struct I1 {
       typedef int X;
     };
     struct I2 : public I1 {
        X x;
     };
  };

Is this legal? The question really boils down to asking whether or not I1 is a dependent type. On the one hand, it doesn't seem to fit any of the qualifications in 13.8.3.2 [temp.dep.type] . On the other, 13.9.4 [temp.expl.spec] allows explicit specialization of a member class of a class template, so something like:

  template <>
  struct S<double>::I1 {
     int X;
  };

is apparently legal. But, then, `X' no longer refers to a type name. So, it seems like `I1' should be classified as dependent. What am I missing?

Erwin Unruh: I wrote that particular piece of text and I just missed the problem above. It is intended to be a dependent type. The reasoning is that I1 is just a shorthand for S<T>::I1 which clearly is dependent.

Suggested Resolution: (Erwin Unruh)

I think the list of what is a dependent type should be extended to cover "a type declared and used within the same template" modulo of phrasing.

(See also paper J16/00-0009 = WG21 N1231. This issue is also somewhat related to issue 205: classes nested inside template classes are, in some sense, "templates," just as non-template member functions of class templates and static data members of class templates are "templates.")