This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 116a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2024-12-19

1810. Invalid ud-suffixes

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

In explaining the relationship between preprocessing tokens and tokens, 5.5 [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.9 [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).

Proposed resolution (June, 2014):

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

[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]

2. Delete 5.13.9 [lex.ext] paragraph 10:

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.

3. Change 12.6 [over.literal] paragraph 1 as follows:

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.

4. Change 16.4.5.3.6 [usrlit.suffix] paragraph 1 as follows:

Literal suffix identifiers (12.6 [over.literal]) that do not start with an underscore are reserved for future standardization.

Additional note, May, 2014:

It has been suggested that the change to 5.5 [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.