Тип `this` в функции статического члена?

Ответ 1

Язык в стандарте можно проследить до n3282, который является разрешением для дефектов 1207 и 1017. В частности, язык представлен в предлагаемой резолюции для дефекта 1207 и поэтому должен рассматриваться в контексте стандарта, поскольку он стоял в то время, когда был устранен дефект. В то время возникла некоторая озабоченность по поводу перезаписи id-выражений в выражения доступа членов, используя *this (9.3.1p3), в частности в контексте объявлений типа trailing-return-type (см. Вопрос 945).

Если мы сравним предлагаемое разрешение с дефектом 1207 на конечном языке в n3282, а затем в стандарте, есть одно существенное отличие от 9.3.1p3:

Дефект 1207:

Когда id-expression (5.1 [expr.prim]), который не является частью синтаксиса доступа к члену класса (5.2.5 [expr.ref]) и не используется для формирования указателя на элемент (5.3.1 [ expr.unary.op]) используется в объявлении функции-члена класса X, если поиск имени (3.4 [basic.lookup]) разрешает имя...

n3282 и С++ 11:

Когда id-expression (5.1 [expr.prim]), который не является частью синтаксиса доступа к члену класса (5.2.5 [expr.ref]) и не используется для формирования указателя на элемент (5.3.1 [ expr.unary.op]) используется в член класса X в контексте, где this может использоваться (5.1.1 [expr.prim.general]), если поиск имени (3.4 [basic.lookup]) разрешает имя [...]

Очевидно, что предлагаемая резолюция о дефекте 1207 предполагала, что выражения id (статическому члену) в статических функциях-членах должны быть преобразованы в выражения для выражения члена *this и, следовательно, потребуется доступ к тип и значение категории this. К тому времени, когда было написано n3282, это было разрешено в пользу преобразования с квалифицированным идентификатором (также 9.3.1p3), который не требует this, но язык в 5.1.1p3 оставался рудиментарным.

Я бы рекомендовал поднимать эту проблему в группе новостей обсуждения стандартов на С++; возможно, удастся устранить рудиментарный язык в редакции.