Created on 2013-11-13.00:00:00 last changed 49 months ago
[Moved to DR at the November, 2014 meeting.]
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., 22.214.171.124. The issue has been returned to "review" status for discussion of this suggestion.
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.8 [lex.ext] paragraph 10:
Some identifiers appearing as ud-suffixes are reserved for future standardization (126.96.36.199.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 188.8.131.52.6 [usrlit.suffix]. —end note]
Change 184.108.40.206.6 [usrlit.suffix] paragraph 1 as follows:
Literal suffix identifiers that do not start with an underscore are reserved for future standardization.
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 (220.127.116.11.6 [usrlit.suffix], cf 12.6 [over.literal] paragraph 1).
|2017-02-06 00:00:00||admin||set||status: drwp -> cd4|
|2015-05-25 00:00:00||admin||set||status: dr -> drwp|
|2015-04-13 00:00:00||admin||set||messages: + msg5325|
|2014-11-24 00:00:00||admin||set||status: ready -> dr|
|2014-07-07 00:00:00||admin||set||status: review -> ready|
|2014-05-27 00:00:00||admin||set||messages: + msg4991|
|2014-05-27 00:00:00||admin||set||status: ready -> review|
|2014-03-03 00:00:00||admin||set||messages: + msg4799|
|2014-03-03 00:00:00||admin||set||status: open -> ready|