CWG2521 User-defined literals and reserved identifiers

[jensmaurer]

CWG2521

As explained in the issue, the normative rule does not give the outcome shown in the example. Even if it did, the significance of whitespace in this context is unfortunate.

CWG solicits EWG input on the handling of this issue.

[erichkeane]

EWG discussed this in our February 6th, 2023 afternoon session in Issaquah.

The following poll was taken:

The form of User Defined Literals that permits a space between the quotes and the name of the literal should be deprecated, and eventually removed. Additionally, the UDL name should be excluded from the restriction in lex.name in the non-deprecated form (sans space).

SF	F	N	A	SA
10	9	1	1	0

Result: Consensus

Forwarding to CWG.

[jensmaurer]

@erichkeane , a User Defined Literal never permits a space between the quotes (if any) and the name of the literal. This is only permitted when declaring a literal operator function as specified in [over.literal]. I am interpreting EWG's poll to refer to the latter, not the former.

[erichkeane]

That is a correct interpretation @jensmaurer. Discussion concentrated on the declarations, and I was apparently imprecise on the poll. However, it was clear (via example) in the room what was meant.

[jensmaurer]

Some implementers are concerned about the lack of space for implementation extensions. The suggestion is to reserve literal suffix identifiers starting with two underscores for the implementation in 16.4.5.3.6 [usrlit.suffix]. EWG is invited to comment on that direction.

CWG2521 has been updated accordingly.

[erichkeane]

EWG discussed this in the February 7th, 2023 Morning session in Issaquah. The following poll was taken.

CWG2521:
Suggest that LEWG amend the proposal for CWG2521 to reserve UDL declarations with double underscores anywhere for the implementation, then forward to CWG.

SF	F	N	A	SA
3	14	5	3	0

Result: Consensus

[erichkeane]

@brycelelbach Attn! This is LEWG's wording, so this has to go to through LEWG first.