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

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

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

Дефект 1207:

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

n3282 и C ++ 11:

Когда id-выражение (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 оставался рудиментарным.

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