hiding of template parameter of member template

Question

from temp.local :

In the definition of a member of a class template that appears outside of the class template definition, the name of a member of the class template hides the name of a template-parameter of any enclosing class templates (but not a template-parameter of the member if the member is a class or function template). [ Example:

template<class T> struct A {
  struct B { /* ... */ };
  typedef void C;
  void f();
  template<class U> void g(U);
};

template<class B> void A<B>::f() {
  B b;              // A's B, not the template parameter
}

template<class B> template<class C> void A<B>::g(C) {
  B b;              // A's B, not the template parameter
  C c;              // the template parameter C, not A's C
}

— end example ]

the problem is that, each compiler, that i have tried ( g++, vc, icc, clang ), treats C in A<B>::g(C) as A's member name and doesn't compile that example.

Is this a common bug.?

Maxey

Well, given that "each compiler" that you tried did that, I can't think of any better definition of "common". That's a rather persuasive argument for describing this as a "common" compiler bug. – Schizophrenia

i meant "common to all compilers, that i have tried". – Maxey

There aren't really that many C++ compilers around. Looks like you've pretty much named them all. They don't exactly grow on trees, you know... It's safe to ignore historical compilers... – Schizophrenia

Related: Why compilation fails when a template parameter name matches an inner class name? – Ekaterina

template<class B> template<class C> void A<B>::g(C) is the body definition for method member of struct A. So, you better not try to make the compiler/developer confuse. In that case, the name of parameter still be hidden. Example, you can call: struct A<int> a; a.g<char>(1); – Unmeet

Answer 1

While the link you gave appears to be a draft and explicitly states it is not a part of any standard (http://eel.is/c++draft/), this particular clause in the draft appears to be identical to ISO C++ 14.6.1, paragraph 7.

So it does indeed seem to be either a common compiler bug or a clause that conflicts with and lost out to other clauses. I verified the example doesn't compile on MacOS Clang v802.0.42). Since you say all the major compilers emit errors here, I would suspect this clause is not reasonable to implement due to conflicts with some other clause(s).

EDIT: I also found a discussion within the standards community here related to this topic. The depth with which it gets discussed here suggests to me that this rule is contentious and may even be changed.

Styrene