This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 112e. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
[Moved to DR at the November, 2014 meeting.]
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.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 (18.104.22.168.6 [usrlit.suffix], cf 12.6 [over.literal] paragraph 1).
Proposed resolution (June, 2014):
Change 5.4 [lex.pptoken] paragraph 4 as follows:
[Example: The program fragment
1Exis parsed as a preprocessing number token (one that is not a valid floating or integer literal token), even though a parse as the pair ofpreprocessing tokens 1and Exmight produce a valid expression (for example, if Exwere 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]
Delete 5.13.9 [lex.ext] paragraph 10:
Some identifiers appearing as ud-suffixes are reserved for future standardization (22.214.171.124.6 [usrlit.suffix]). A program containing such a ud-suffix is ill-formed, no diagnostic required.
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: someliteral suffix identifiers are reserved for future standardization; see 126.96.36.199.6 [usrlit.suffix]. —end note]
Change 188.8.131.52.6 [usrlit.suffix] paragraph 1 as follows:
Literal suffix identifiers 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.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., 184.108.40.206. The issue has been returned to "review" status for discussion of this suggestion.