1

Dependent names are not clearly defined in the C++ standard, so it leaves a lot to be desired in terms of determining what a dependent name is, which leads me to this question: Are unqualified names of non-static data members with dependent types dependent? For example:

template<typename T>
struct S { T t; };

Is the name t here a dependent name? The type certainly is dependent, but it's not clear if the name is, since it can always be resolved to refer to a member.

curiousguy
  • 8,038
  • 2
  • 40
  • 58
Krystian S
  • 1,586
  • 7
  • 23
  • 1
    I believe the full name is not `t`, but `S::t`. Thus it would be dependent. But I'm not sure enough about that to leave an actual answer. – Mark Ransom Aug 17 '19 at 02:35
  • @NicolBolas Several sources seem to state that the wording is incomplete, and that "dependent name" applies to types, and names of data members as well. – Krystian S Aug 17 '19 at 02:56
  • 1
    @KrystianS: You tagged the question with [tag:language-lawyer], so you want an answer based entirely on the standard, not what "several sources seem to state". Your question does not make sense when applied to the standard, because a bare identifier is *never* a "dependent name" in accord with the definition of that term. – Nicol Bolas Aug 17 '19 at 02:57
  • @KrystianS: "*Several sources seem to state that the wording is incomplete, and that "dependent name" applies to types, and names of data members as well.*" I think this comes from the difference between the way *people* use the term "dependent name" and the way the *standard* uses it. Because I had never actually looked up the term, and it was a lot more narrow than what I had been led to believe. But the standard is consistent with itself on the usage of this term; the problem is *other people*, not the standard. – Nicol Bolas Aug 17 '19 at 03:12
  • @NicolBolas Ok, then going by the definition in the standard, a dependent name is only an unqualified-id used in a function call that meets the requirement of that list> – Krystian S Aug 17 '19 at 03:18
  • @NicolBolas "_you want an answer based entirely on the standard_" That isn't true. Many LL Q are correctly answered based on quotes outside the std. – curiousguy Aug 17 '19 at 13:04

1 Answers1

2

No, t is not dependent. While there is an open issue about expanding the definition of a dependent name, the idea of a name being dependent is that lookup for it is deferred. (Even without ADL, consider the lookup for T::foo, which might be a function, a function template, or a data member (without template or typename).) That’s not the case here; t (in a context inside S) is immediately resolved to the class member.

Davis Herring
  • 36,443
  • 4
  • 48
  • 76
  • The official definition in the standard only says that a unqualified-id in a function call in certain contexts is a dependent name, so unless `T::foo` was in a function call, it wouldn't be a dependent name, right? – Krystian S Aug 17 '19 at 03:29
  • @KrystianS: Correct: you have identified the problem in the standard. Note that C++11 as published did not require that a dependent name be unqualified, but its definition had other problems. There is a chance all this will be sorted out while fixing bugs for C++20. – Davis Herring Aug 17 '19 at 04:37
  • Looks like the issue you linked had the same clause in mind as me: how dependent names are considered equivalent. I'm assuming the intent is to make it apply to members of an unknown specialization as well, since there currently is a hole in the wording (in a template declaration, how do you know if T::x and U::x are equivalent!?) – Krystian S Aug 17 '19 at 06:33
  • 1
    @KrystianS: That case doesn’t matter—the `T` and `U` being different is enough to make them inequivalent, even if the functions called would be the same for some `T` and `U`. – Davis Herring Aug 17 '19 at 06:37
  • Yes, but no current rule actually states that. – Krystian S Aug 17 '19 at 09:13
  • For example: ```template void f() { } template void f() { }``` a pedantic reading on the standard would find that according to the rules for checking if template parameters are equivalent, they must both declare non-type template parameters, however, since the types that `T::a` and `T::b` denote are unknown, there exists no provision for comparing them. – Krystian S Aug 17 '19 at 11:48
  • 1
    @KrystianS: There is a current rule: such types are compared as [“expressions involving template parameters”](http://eel.is/c++draft/temp.over.link#6.sentence-3), which is admittedly unsatisfying since a type name is not an expression. – Davis Herring Aug 17 '19 at 15:19
  • Ah, perfect - that's all I needed, thank you. I remember seeing this rule before, but somehow I missed it this time. – Krystian S Aug 17 '19 at 16:34