Does any wording specify how the names of members of unknown specializations and of the current instantiation are looked up? [temp.res] p10 has a very informal definition:
When looking for the declaration of a name used in a template definition, the usual lookup rules are used for non-dependent names. The lookup of names dependent on the template parameters is postponed until the actual template argument is known.
[temp.dep] p2 specifies that dependent names only apply to unqualified-id's in function calls with type-dependent parameters, so going strictly from this definition, all other names would be non-dependent, which would not makes sense for something like this:
template<typename B>
struct A : B
{
void f()
{
this->a += 1; // a here is a member of an unknown specialization, but is not a dependent name
}
};
Here, lookup would have to be postponed until a specialization is instantiated, however, there is no such wording that specifies this that I have found because a is not a dependent name.
The only explanation I can think of for this is that the definition dependent name differs from "a name that depends on template parameters". Even then, its not defined what it would mean for a name to depend on a template parameter.
As for members of the current instantiation, there is also no wording specifying when they are looked up and bound. For example:
template<typename T>
struct S
{
T a;
void f()
{
++a; // a is a member of the current instantiation, but not a dependent name
}
};
Lookup and binding in this case would not need to be postponed until a specialization is instantiated, as name hiding rules would ensure that a would always refer to the member a, or another more local name that was declared within the template definition. However, as with the previous case, there is no such wording that actually specifies what would happen in this case either. Certainly, the type of a would be dependent on a template parameter, but the actual meaning is easily deduced, as a function cannot acquire its type from a dependent type.
Is this just a defect in the standard?
