[LLVMbugs] [Bug 7858] New: a template type parameter name should hide a same-named member of that type
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Mon Aug 9 23:55:34 PDT 2010
http://llvm.org/bugs/show_bug.cgi?id=7858
Summary: a template type parameter name should hide a
same-named member of that type
Product: clang
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P
Component: C++
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: zhanyong.wan at gmail.com
CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com
$ cat lookup_test.cc
template <typename T> void f(T* t) {
t->T::foo();
}
struct S {
void foo() {}
enum T { SOME_CONSTANT };
};
int main() {
S s;
f(&s);
}
$ clang lookup_test.cc
lookup_test.cc:2:7: error: expected a class or namespace
t->T::foo();
^
lookup_test.cc:12:3: note: in instantiation of function template specialization
'f<S>' requested here
f(&s);
^
Clang seems to think that the name T in "t->T::foo()" resolves to S::T. I tend
to think that it should be the template parameter T (and thus the code should
be valid).
I checked the C++03 standard 14.6 [temp.res] for the rules regarding name
resolution in template definitions. Unfortunately I didn't find anything
conclusive. The reasons for my belief that the code is valid are:
- Both GCC and Comeau accept the code.
- It would be a silly design mistake on the C++ standard committee's part if
this code is invalid, as the author of f<>() has no knowledge on where it will
be used and cannot anticipate whether it will be instantiated with a type that
has a member named T. If the code is invalid, regardless of what name the
author of f<>() picks for its template parameter, f will fail to instantiate
for some type that happens to have a member with the same name. This doesn't
make sense and basically makes it impossible to write truly generic functions.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the llvm-bugs
mailing list