76

In C++ 5.1.1/3 [expr.prim.general] it says:

The type and value category [of this] are defined within a static member function.

What does this mean? How is it relevant?

Note that:

this shall not appear in the declaration of a static member function

Joseph Mansfield
  • 108,238
  • 20
  • 242
  • 324
Andrew Tomazos
  • 66,139
  • 40
  • 186
  • 319
  • 31
    Somebody, phone Bjarne! – Alexander Shukaev May 13 '13 at 14:55
  • The text you quote isn't in N3242. Is the final standard publicly available somewhere? – zwol May 13 '13 at 14:57
  • Its from N3485 (Nov 2012) – Andrew Tomazos May 13 '13 at 14:58
  • 3
    @Zack: Yes, but you have to pay for it. The cheapest source is probably [here](http://webstore.ansi.org/RecordDetail.aspx?sku=INCITS%2fISO%2fIEC+14882-2012). The closest draft to the published standard is [n3337](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf) – Mike Seymour May 13 '13 at 15:01
  • Did you get a reasonable explanation for the alluded "vestigial language" mentioned by @ecatmur in his answer below? I have seen your discussion with Jens Maurer [here](https://groups.google.com/a/isocpp.org/d/msg/std-discussion/0trzTFt_tzk/lY8lOmzUNJkJ), but AFAICT your question has not been answered yet. – Belloc Sep 01 '18 at 18:57

1 Answers1

78

The language in the standard can be traced to n3282, which is a resolution for defects 1207 and 1017. In particular, the language appears in the proposed resolution for defect 1207, and thus should be considered in the context of the standard as it stood at the time that defect was addressed. At that time there was some concern over the rewriting of id-expressions into member access expressions using *this (9.3.1p3), in particular in the context of trailing-return-type declarations (see issue 945).

If we compare the proposed resolution to defect 1207 to the eventual language in n3282 and subsequently in the standard, there is one significant difference to 9.3.1p3:

Defect 1207:

When an id-expression (5.1 [expr.prim]) that is not part of a class member access syntax (5.2.5 [expr.ref]) and not used to form a pointer to member (5.3.1 [expr.unary.op]) is used in the declaration of a member function of class X, if name lookup (3.4 [basic.lookup]) resolves the name...

n3282 and C++11:

When an id-expression (5.1 [expr.prim]) that is not part of a class member access syntax (5.2.5 [expr.ref]) and not used to form a pointer to member (5.3.1 [expr.unary.op]) is used in a member of class X in a context where this can be used (5.1.1 [expr.prim.general]), if name lookup (3.4 [basic.lookup]) resolves the name [...]

It is apparent that the proposed resolution to defect 1207 carried the belief that id-expressions (to a static member) within a static member functions would need to be transformed to *this member access expressions and thus would need access to the type and value category of this. By the time n3282 was written this had been resolved in favour of the qualified-id transformation (also 9.3.1p3) which does not require this, but the language in 5.1.1p3 remained vestigially.

I would recommend raising this issue on the C++ standards discussion newsgroup; it may be possible to get the vestigial language removed editorially.

ecatmur
  • 152,476
  • 27
  • 293
  • 366