Title
User-defined literals and reserved identifiers
Status
open
Section
12.6 [over.literal]
Submitter
Jim X

Created on 2022-01-07.00:00:00 last changed 2 weeks ago

Messages

Date: 2022-11-20.07:54:16

CWG 2022-11-11

CWG feels that the ostensible significance of whitespace in this context is unfortunate. In addition, since the normative rule is not consistent with the example, CWG solicits EWG input on the handling of this issue.

Date: 2022-01-07.00:00:00

The example in 12.6 [over.literal] paragraph 8 has the following lines:

  double operator""_Bq(long double);  // OK: does not use the reserved identifier _Bq (5.10)
  double operator"" _Bq(long double); // ill-formed, no diagnostic required:
                                      // uses the reserved identifier _Bq (5.10)

The referenced rule in 5.10 [lex.name] is in bullet 3.1:

Each identifier that contains a double underscore __ or begins with an underscore followed by an uppercase letter is reserved to the implementation for any use.

The distinction being drawn in the user-defined literal example apparently relies on the grammar for literal-operator-id at the beginning of 12.6 [over.literal]:

    literal-operator-id:
      operator string-literal identifier
      operator user-defined-string-literal

The second production does not mention the syntactic non-terminal identifier, so the literal-operator-id operator""_Bq presumably does not run afoul of the restriction in 5.10 [lex.name]. However, the grammar for user-defined-string-literal in 5.13.8 [lex.ext] is:

    user-defined-string-literal:
      string-literal ud-suffix

    ud-suffix:
      identifier

There doesn't seem to be a rule that exempts the identifier that is the ud-suffix of a user-defined-string-literal from the restriction in 5.10 [lex.name]. Either the example is incorrect or there needs to be a refinement of the rule in 5.10 [lex.name].

History
Date User Action Args
2022-11-20 07:54:16adminsetmessages: + msg7048
2022-01-07 00:00:00admincreate