Question

I have some code that, for the purposes of this question, boils down to

template<typename T>
class TemplateClass : public T {
 public:
  void method() {}
  template<typename U>
  static void static_method(U u) { u.TemplateClass::method(); }
};

class EmptyClass {};

int main() {
  TemplateClass<TemplateClass<EmptyClass> > c;
  TemplateClass<EmptyClass>::static_method(c);
}

I’ve tried to compile it with several versions of two compilers. GCC 4.2, 4.4, 4.6 accept it without complaint. Clang 2.9 and SVN trunk as of November 14 reject it with the following error message:

example.cc:6:38: error: lookup of 'TemplateClass' in member access expression is
      ambiguous
  static void static_method(U u) { u.TemplateClass::method(); }
                                     ^
example.cc:13:3: note: in instantiation of function template specialization
      'TemplateClass<EmptyClass>::static_method<TemplateClass<TemplateClass<EmptyClass>
      > >' requested here
  TemplateClass<EmptyClass>::static_method(c);
  ^
example.cc:2:7: note: lookup in the object type
      'TemplateClass<TemplateClass<EmptyClass> >' refers here
class TemplateClass : public T {
      ^
example.cc:2:7: note: lookup from the current scope refers here
1 error generated.

Which one is wrong? I can work around Clang by changing

  static void static_method(U u) { u.TemplateClass::method(); }

to

  static void static_method(U u) { u.TemplateClass<T>::method(); }

but I’d like be confident in my understanding of when it’s OK to elide the template parameters.

---

EDIT: I had thought that the ambiguity was between the two instantiations of TemplateClass. The following code compiles with GCC and Clang, calling that hypothesis into doubt:

class E {};

template<typename T>
class A : public T {
 public:
  void method() {}
};

int main() {
  A<A<E> > a;
  a.A::method();
}

Answer 1

I believe that clang is correctly rejecting this code.

The ambiguity that clang finds can be reproduced with a less complicated example:

template<typename T>
class TemplateClass {
 public:
  void method() {}
  template<typename U>
  static void static_method(U u) { u.TemplateClass::method(); }                                  
};

struct A {};
struct B {};

int main() {
  TemplateClass<A> c;
  TemplateClass<B>::static_method(c);
}

Here the inheritance in the template is omitted and two independent classes are used for the instantiations. The error produced by clang remains the same.

First of all, in the scope of TemplateClass<T> the name TemplateClass refers to TemplateClass<T>, due to class name injection. This is the reason that the static method can use TemplateClass::method instead of a more explicit TemplateClass<T>::method.

The name lookup used to interpret u.TemplateClass::method in the static method is defined in “3.4.5 Class member access [base.lookup.classref]” of the C++11 and C++98 standards.

The relevant part is 3.4.5/4:

If the id-expression in a class member access is a qualified-id of the form

class-name-or-namespace-name::...

[…]

This is the case here. The id-expression is the part to the right of the . and in our case this is the qualified name TemplateClass::method.

[…]
the class-name-or-namespace-name following the . or -> operator is looked up both in the context of the
entire postfix-expression and in the scope of the class of the object expression.

The “scope of the entire postfix-expression” is the body of the static function, and in this static function TemplateClass refers to TemplateClass<B>, since the function is a member of that class (we called TemplateClass<B>::static_method).

So in this scope the name refers to TemplateClass<B>.

The “object expression” is the part left of ., in our case c. The class of c is TemplateClass<A> and in the scope of this class, TemplateClass refers to TemplateClass<A>.

So, depending on the scope used for the lookup, the name refers to a different entity.

The standard now says:

If the name is found in both contexts, the class-name-or-namespace-name shall refer to the same entity.

This is not the case in our program. The program is ill-formed, and the compiler is required to give a diagnostic message.

The ambiguity stays the same if you replace B with TemplateClass<A>, as used in the question.