C++ Logo

sg16

Advanced search

Re: [SG16] SG16 meeting summary for February 26th, 2020

From: Steve Downey <sdowney_at_[hidden]>
Date: Tue, 3 Mar 2020 21:24:44 -0500
It looks like the grammar in [cpp] says that macro name and argument list
are identifiers.

I'm not completely convinced that normalization needs to apply before phase
7, but they probably should follow the character set restriction.

The NFC concern is for matching symbols canonically, and that's less of a
concern with macro names, although it is of some concern.

On Tue, Mar 3, 2020, 20:24 Hubert Tong <hubert.reinterpretcast_at_[hidden]>
wrote:

> On Tue, Mar 3, 2020 at 7:33 PM Tom Honermann <tom_at_[hidden]> wrote:
>
>> On 3/2/20 2:53 PM, Hubert Tong wrote:
>>
>> With respect to Jens's comments as recorded re: P1949 (Identifier syntax):
>>
>> You are referring to these comments, yes?
>>
>> - Jens replied that preprocessing-token is distinct and that they get
>> converted into identifiers, keywords, etc... at a particular translation
>> phase.
>> - Jens added that this occurs in translation phase 7 per [lex.phases]p1.7
>> and [lex.token]p1. Core language wording should be added here to state that
>> an identifier shall be in NFC form.
>>
> Yes.
>
>>
>> Deferring the NFC restriction to phase 7 would not cover the need to
>> match macro and macro parameter names to their corresponding references.
>>
>> That sounds correct to me; at least for the proposal as written. My
>> interpretation of the discussion so far has been that there has been no
>> intent to address naming of macros and macro parameters. This is why I
>> asked during the telecon if the paper should address (preprocessing) tokens
>> as well as identifiers. I tend to think that it should since the same
>> concerns we have for identifiers seem to apply to preprocessing tokens.
>>
> The existing text of the standard is not very helpful around this:
> preprocessing tokens known as identifiers exist; the conversion from
> preprocessing tokens to tokens may decide that the resulting token is a
> keyword. It would be a consistent approach to allow deviation from NFC form
> except in problematic cases. The preprocessing tokens not in NFC form could
> be discarded or stringized during preprocessing.
>

Received on 2020-03-03 20:27:39