Является ли имя нестатического члена зависимым при использовании в нестатической функции-члене?

Ответ зависит от того, m можно посмотреть, чтобы определить, что он является членом текущего экземпляра. Id-выражение m преобразован в доступ к члену класса (*this).mЭто означает, что применимы правила поиска квалифицированного имени в пределах доступа члена класса.

Как правило, тип зависимого от типа выражения не может быть определен. Не совсем ясно, следует ли делать исключение для (*this). а также this->, Выражение, содержащее this зависит от типа, но оба (*this). а также this-> однозначно назовите текущий экземпляр.

m

Выражение m действительно не зависит от типа, потому что относится к члену текущего экземпляра.

В контексте нестатического члена, m превращается в выражение доступа члена класса (*this).m,

[Class.mfct.non-статические] / 3

Когда id-выражение (5.1), которое не является частью синтаксиса доступа к члену класса (5.2.5) и не используется для формирования указателя на член (5.3.1), используется в члене класса X в контексте, где это можно использовать (5.1.1), если поиск по имени (3.4) разрешает имя в выражении id в нестатический нетипичный член некоторого класса Cи если или id-выражение потенциально оценивается или C является X или базовый класс X, id-выражение преобразуется в выражение доступа к члену класса (5.2.5) с использованием (*this)

Преобразование происходит потому, что m является членом класса A используется внутри нестатического члена класса A,

[Expr.prim.general] / 3

Если объявление объявляет функцию-член или шаблон функции-члена класса X, the expressionthis`
является значением типа «указатель на cv-qualifier-seq X» между необязательным cv-qualifer-seq и концом
определение функции, член-декларатор или декларатор. Он не должен появляться перед необязательным cv-qualifier-seq
и он не должен появляться в объявлении статической функции-члена (хотя ее тип и значение
категории определяются внутри статической функции-члена, так как они находятся внутри нестатической функции-члена).

[Expr.prim.general] / 5

Выражение this не должно появляться ни в каком другом контексте. [ Пример:

class Outer {
int a[sizeof(*this)]; // error: not inside a member function
unsigned int sz = sizeof(*this); // OK: in brace-or-equal-initializer

void f() {
int b[sizeof(*this)]; // OK

struct Inner {
int c[sizeof(*this)]; // error: not inside a member function of Inner
};
}
};

— конец примера]

Приведенный выше пример явно разрешает использование this в пределах sizeof выражение в нестатическом члене.

[Temp.dep.expr] / 2

this зависит от типа, если тип класса включающей функции-члена зависит

Следовательно this зависит от типа в определении функции-члена шаблона класса.

[Temp.dep.expr] / 1

За исключением случаев, описанных ниже, выражение зависит от типа, если любое подвыражение зависит от типа.

Тем не менее, вышеупомянутое отменяется исключением из [temp.dep.expr] / 5, приведенным в вопросе.

this->m

Выражение this->m также не зависит от типа, потому что это также выражение доступа к члену класса, которое ссылается на член текущего экземпляра.

std::declval<A>().m

Выражение std::declval<A>().m должен быть зависимым от типа, так как тип возвращаемого значения std::declval<A>() может зависеть от типа A,

[Temp.local] / 1

Как и обычные (не шаблонные) классы, шаблоны классов имеют имя введенного класса (раздел 9). Инъекционный класс-
имя может использоваться как имя шаблона или имя типа. Когда он используется со списком аргументов шаблона,
в качестве аргумента шаблона для параметра шаблона шаблона или в качестве окончательного идентификатора в уточненном спецификаторе типов
объявления шаблона класса друга, оно ссылается на сам шаблон класса. В противном случае это эквивалентно
к имени шаблона, за которым следуют параметры шаблона шаблона класса, заключенного в <>

Следовательно A превращается в A<T>,

[Temp.dep.type] / 8

Тип зависит, если он

• параметр шаблона,

• простой-шаблон-идентификатор, в котором либо имя шаблона является параметром шаблона, либо любым из шаблона
  Аргументы являются зависимым типом или выражением, которое зависит от типа или значения

Это подтверждает, что A<T> является зависимым типом, что означает, что A также зависит.

[Temp.dep.expr] / 3

Выражение id зависит от типа, если оно содержит

• идентификатор шаблона, который зависит,

Так std::declval<A> является зависимым от типа выражением. Это следует из того std::declval<A>().m зависит от типа, потому что содержит зависимое от типа подвыражение std::declval<A>,

&A::m

Выражение &A::m логически должен быть зависимым от типа, потому что он имеет тип int A<T>::* который является зависимым типом.

Выражение &A::m превращается в &A<T>::m так как A является введенным именем класса — как показано выше.

Id-выражение A<T>::m зависит от типа в соответствии с [temp.dep.expr] / 3, потому что он содержит идентификатор шаблона A<T> это зависит. Поэтому выражение &A<T>::m зависит от типа в соответствии с [temp.dep.expr] / 1.

A::m

Выражение A::m превращается в A<T>::m так как A является введенным именем класса — как показано выше. Выражение A<T>::m далее преобразуется в (*this).A<T>::m так как A<T>::m называет нестатический член A,

Id-выражение A<T>::m зависит от типа в соответствии с [temp.dep.expr] / 3, потому что он содержит идентификатор шаблона A<T> это зависит. Выражение доступа к члену класса (*this).A<T>::m ссылается на член текущего экземпляра, поэтому [temp.dep.expr] / 5 применяется, но не делает выражение зависимым от типа — и не противоречит [temp.dep.expr] / 3.

Дефект?

Учитывая приведенную выше интерпретацию, id-выражение, именующее члена A квалифицированный с A или же A<T> станет зависимым от типа, что кажется ненужным и противоречивым. Учтите, что имя типа уточняется A или же A<T> не будет зависеть в том же контексте.

Если намерение [temp.dep.expr] / 5 таково (*this).m не зависит от типа, то из этого следует, что (*this).A<T>::m также не должен зависеть от типа. С другой стороны, возможно, что имя нестатического члена всегда зависит. Я отправил вопрос на std-обсуждение, чтобы прояснить этот момент: https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/gEvZ7mmXEC8