When a dependent base class is the current instantiation
13.8.3 [temp.dep]
James Widman

Created on 2006-08-24.00:00:00 last changed 49 months ago


Date: 2014-11-15.00:00:00

[Moved to DR at the November, 2014 meeting.]

Date: 2014-02-15.00:00:00

Proposed resolution (February, 2014):

  1. Add the following as a new paragraph before [temp.dep.type] paragraph 4:

  2. A dependent base class is a base class that is a dependent type and is not the current instantiation. [Note: a base class can be the current instantiation in the case of a nested class naming an enclosing class as a base. —end note] [Example:

      template<class T> struct A {
        typedef int M;
        struct B {
          typedef void M;
          struct C;
      template<class T> struct A<T>::B::C : A<T> {
        M m; // OK, A<T>::M

    end example]

    A name is a member of the current instantiation if...

  3. Change 13.8.2 [temp.local] paragraph 9 as follows:

  4. In the definition of a class template or in the definition of a member of such a template that appears outside of the template definition, for each non-dependent base class ( [temp.dep.type]) which does not depend on a template-parameter (13.8.3 [temp.dep]), if the name of the base class or the name of a member of the base class is the same as the name of a template-parameter, the base class name or member name hides the template-parameter name (_N4868_.6.4.10 [basic.scope.hiding]). [Example:...
  5. Change 13.8.3 [temp.dep] paragraph 3 as follows:

  6. In the definition of a class or class template, if a base class depends on a template-parameter, the base class scope the scope of a dependent base class ( [temp.dep.type]) is not examined during unqualified name lookup either at the point of definition of the class template or member or during an instantiation of the class template or member. [Example:...
Date: 2012-09-15.00:00:00

Additional note (September, 2012):

See also issue 1526 for additional analysis demonstrating that this issue is still current despite the changes to the description of the current instantiation. The status has consequently been changed back to "open" for further consideration.

Date: 2011-08-15.00:00:00

Notes from the August, 2011 meeting:

The recent changes to the handling of the current instantiation may have sufficiently addressed this issue.

Date: 2006-08-24.00:00:00

Is the following example well-formed?

    template<class T> struct A {
         typedef int M;
         struct B {
             typedef void M;
             struct C;

    template<class T> struct A<T>::B::C : A<T> {
         M  // A<T>::M or A<T>::B::M?

13.8.3 [temp.dep] paragraph 3 says the use of M should refer to A<T>::B::M because the base class A<T> is not searched because it's dependent. But in this case A<T> is also the current instantiation ( [temp.dep.type]) so it seems like it should be searched.

Date User Action Args
2017-02-06 00:00:00adminsetstatus: drwp -> cd4
2015-05-25 00:00:00adminsetstatus: dr -> drwp
2015-04-13 00:00:00adminsetmessages: + msg5413
2014-11-24 00:00:00adminsetstatus: ready -> dr
2014-03-03 00:00:00adminsetmessages: + msg4852
2014-03-03 00:00:00adminsetstatus: drafting -> ready
2012-11-03 00:00:00adminsetstatus: open -> drafting
2012-09-24 00:00:00adminsetmessages: + msg3987
2012-09-24 00:00:00adminsetstatus: review -> open
2011-09-06 00:00:00adminsetmessages: + msg3506
2011-04-10 00:00:00adminsetstatus: open -> review
2006-08-24 00:00:00admincreate