This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115e. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-11-11
[Voted into the WP at the March, 2011 meeting as paper N3283.]
13.8.3.2 [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:
It is handled like the unqualified-id case, looking only in non-dependent base classes and not being a dependent type.
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.
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.
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.