Title
Invalid ud-suffixes
Status
cd4
Section
5.13.8 [lex.ext]
Submitter
Gabriel Dos Reis

Created on 2013-11-13.00:00:00 last changed 49 months ago

Messages

Date: 2014-11-15.00:00:00

[Moved to DR at the November, 2014 meeting.]

Date: 2014-05-27.00:00:00

Additional note, May, 2014:

It has been suggested that the change to 5.4 [lex.pptoken] paragraph 4 in the proposed resolution would be simpler and better if it did not venture into questions about user-defined literals but simply relied on a string that is a valid pp-number but not a valid floating-point number, as was the case before the introduction of user-defined literals, e.g., 1.2.3.4. The issue has been returned to "review" status for discussion of this suggestion.

Date: 2014-06-15.00:00:00

Proposed resolution (June, 2014):

  1. Change 5.4 [lex.pptoken] paragraph 4 as follows:

  2. [Example: The program fragment 1Ex 0xe+foo is parsed as a preprocessing number token (one that is not a valid floating or integer literal token), even though a parse as the pair of three preprocessing tokens 1 0xe, +, and Ex foo might produce a valid expression (for example, if Ex foo were a macro defined as +1). Similarly, the program fragment 1E1 is parsed as a preprocessing number (one that is a valid floating literal token), whether or not E is a macro name. —end example]
  3. Delete 5.13.8 [lex.ext] paragraph 10:

  4. Some identifiers appearing as ud-suffixes are reserved for future standardization (16.4.5.3.6 [usrlit.suffix]). A program containing such a ud-suffix is ill-formed, no diagnostic required.
  5. Change 12.6 [over.literal] paragraph 1 as follows:

  6. The string-literal or user-defined-string-literal in a literal-operator-id shall have no encoding-prefix and shall contain no characters other than the implicit terminating '\0'. The ud-suffix of the user-defined-string-literal or the identifier in a literal-operator-id is called a literal suffix identifier. [Note: some Some literal suffix identifiers are reserved for future standardization; see 16.4.5.3.6 [usrlit.suffix]. end note] A declaration whose literal-operator-id uses such a literal suffix identifier is ill-formed; no diagnostic required.
  7. Change 16.4.5.3.6 [usrlit.suffix] paragraph 1 as follows:

  8. Literal suffix identifiers (12.6 [over.literal]) that do not start with an underscore are reserved for future standardization.
Date: 2017-02-06.00:00:00

In explaining the relationship between preprocessing tokens and tokens, 5.4 [lex.pptoken] paragraph 4 contains the following example:

[Example: The program fragment 1Ex is parsed as a preprocessing number token (one that is not a valid floating or integer literal token), even though a parse as the pair of preprocessing tokens 1 and Ex might produce a valid expression (for example, if Ex were a macro defined as +1).

This analysis does not take into account the addition of user-defined literals. In fact, 1Ex matches the rule for a user-defined-integer-literal, which is then ill-formed because it uses a reserved ud-suffix (5.13.8 [lex.ext] paragraph 10), as well as (presumably) because of a lookup failure for a matching literal operator, raw literal operator, or literal operator template.

More generally, it might be preferable to eliminate the restriction on the use of a reserved ud-suffix and rely simply on the fact that it is ill-formed to declare a literal operator, raw literal operator, or literal operator template with a reserved literal suffix identifier (16.4.5.3.6 [usrlit.suffix], cf 12.6 [over.literal] paragraph 1).

History
Date User Action Args
2017-02-06 00:00:00adminsetstatus: drwp -> cd4
2015-05-25 00:00:00adminsetstatus: dr -> drwp
2015-04-13 00:00:00adminsetmessages: + msg5325
2014-11-24 00:00:00adminsetstatus: ready -> dr
2014-07-07 00:00:00adminsetstatus: review -> ready
2014-05-27 00:00:00adminsetmessages: + msg4991
2014-05-27 00:00:00adminsetstatus: ready -> review
2014-03-03 00:00:00adminsetmessages: + msg4799
2014-03-03 00:00:00adminsetstatus: open -> ready
2013-11-13 00:00:00admincreate