Movatterモバイル変換

[Moved to DR at the April, 2013 meeting.]

Proposed resolution (October, 2012):

1. Change 5.11 [lex.name] paragraph 2 as follows:

The identifiers in Table 3 have a special meaning when appearing in acertain context. When referred to in the grammar, these identifiersare used explicitly rather than using theidentifier grammarproduction.Unless otherwise specified, any ambiguity as towhether a given identifier has a special meaning is resolved tointerpret the token as a regularidentifier.

2. Change Clause 11 [class] paragraph 3 as follows:

If a class is marked with theclass-virt-specifierfinal and it appears as abase-type-specifier in abase-clause (11.7 [class.derived]), the program isill-formed.Whenever aclass-key is followed by aclass-head-name, theidentifierfinal, and acolon or left brace,final is interpreted as aclass-virt-specifier. [Example:

  struct A;  struct A final {};      // OK: definition ofstruct A,                          // not value-initialization of variablefinal  struct X {   struct C { constexpr operator int() { return 5; } };   struct B final : C{};  // OK: definition of nested classB,                          // not declaration of a bit-field memberfinal  };

—end example]

The ambiguity in an example like

  struct A final { };

is resolved by 5.11 [lex.name] paragraph 2 to be thedeclaration of a variable namedfinal:

any ambiguity as to whether a givenidentifier has a specialmeaning is resolved to interpret the token as a regularidentifier.

Similarly, in an example like

  struct C { constexpr operator int() { return 5; } };  struct A {   struct B final : C{};  };

final is taken as the name of a bit-field member rather thanas the name of a nested class.