This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115b. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-08-20
[Moved to DR at the April, 2013 meeting.]
The ambiguity in an example like
struct A final { };
is resolved by 5.10 [lex.name] paragraph 2 to be the declaration of a variable named final:
any ambiguity as to whether a given identifier has a special meaning is resolved to interpret the token as a regular identifier.
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 than as the name of a nested class.
Proposed resolution (October, 2012):
Change 5.10 [lex.name] paragraph 2 as follows:
The identifiers in Table 3 have a special meaning when appearing in a certain context. When referred to in the grammar, these identifiers are used explicitly rather than using the identifier grammar production. Unless otherwise specified, any ambiguity as to whether a given identifier has a special meaning is resolved to interpret the token as a regular identifier.
Change Clause 11 [class] paragraph 3 as follows:
If a class is marked with the class-virt-specifier final and it appears as a base-type-specifier in a base-clause (11.7 [class.derived]), the program is ill-formed. Whenever a class-key is followed by a class-head-name, the identifier final, and a colon or left brace, final is interpreted as a class-virt-specifier. [Example:
struct A; struct A final {}; // OK: definition of struct A, // not value-initialization of variable final struct X { struct C { constexpr operator int() { return 5; } }; struct B final : C{}; // OK: definition of nested class B, // not declaration of a bit-field member final };—end example]