Qualified name lookup in the current instantiation
Section [temp.dep.type]
Doug Gregor

Created on 2010-03-05.00:00:00 last changed 96 months ago


Date: 2011-03-15.00:00:00

[Voted into the WP at the March, 2011 meeting as paper N3283.]

Date: 2010-11-15.00:00:00

Additional note (November, 2010):

The overall treatment of dependent base classes in handling a qualified-id in which the nested-name-specifier names the current instantiation or in a member access expression where the object expression is *this is not very clear. It would be helpful if the resolution of this issue could clarify the overall treatment while dealing with the mixed dependent/non-dependent case given in the example.

Date: 2010-11-15.00:00:00

Notes from the November, 2010 meeting:

The CWG agreed that if a name is found in a non-dependent base, the type should be treated as non-dependent also.

Date: 2010-03-05.00:00:00 [temp.dep.type] paragraph 4 treats unqualified-ids and qualified-ids in which the nested-name-specifier refers to the current instantiation as equivalent. However, the lookups associated with these two id-expressions are different in the presence of dependent base classes (13.8.3 [temp.dep] paragraph 3): with an unqualified-id, a dependent base class scope is never examined, while with a qualified-id it is. The current wording does not specify how an example like the following is to be handled:

  template<typename T> struct B {};
  struct C { typedef int type; };

  template<typename T>
  struct A : B<T>, C {
    template<typename U> type a(); // #1
    template<typename U> typename A<T>::type a(); // #2: different from #1?

  template<typename T> template<typename U> typename A<T>::type
    A<T>::a() { ... } // defines #1 or #2?

There seem to be two possible strategies for the handling of typename A<T>::type:

  1. It is handled like the unqualified-id case, looking only in non-dependent base classes and not being a dependent type.

  2. Since the current instantiation has dependent base classes, it is handled as a dependent type.

EDG seems to be doing the former, g++ the latter.

Date User Action Args
2014-03-03 00:00:00adminsetstatus: fdis -> c++11
2011-04-10 00:00:00adminsetmessages: + msg3393
2011-04-10 00:00:00adminsetstatus: drafting -> fdis
2010-11-29 00:00:00adminsetmessages: + msg3128
2010-11-29 00:00:00adminsetmessages: + msg3127
2010-11-29 00:00:00adminsetstatus: open -> drafting
2010-03-05 00:00:00admincreate