On 3/11/26 17:57, Tom Honermann via SG16 wrote:
> On 3/10/26 7:24 PM, Hubert Tong wrote:
>> Especially for the second poll, the two models generate different, valid interpretations of
>> f"{" "name" "}"
>>
>> 1. name is the sole pp-token in the extraction field.
>> 2. The extraction token consists of three pp-tokens: " ", name, and " ".
>>
> Interesting. My expectation has been aligned with the first case, but the latter (I think) has the nice property of avoiding potentially recursive macro expansion. Consider:

For these string interpolation papers, we have to be super-careful to clearly
keep apart
 - lexing (input: characters, output: pp-tokens)
 - phase 4 macro replacement (input: pp-tokens, output: pp-tokens)
 - phase 5: string literal concatenation (input: pp-tokens, output: pp-tokens)
 - phase 6/7 (input: pp-tokens, output: tokens)

> constexpr char MACRO[] = "ORCAM";
> #define MACRO "MACRO"
> f"{" MACRO "}"
>
> MACRO must be initially expanded to allow string literal concatenation to occur.

Why? We can't go back to phase 3 (lexing) from phase 5 (string concatenation)
in the current C++ framework. If we wanted to, that's a major change none of
the papers is equipped to tackle.

Each of the papers needs to be super-clear on what the processing function
of the three stages mentioned above is, if it's altered by the respective
proposal. If we want to commingle or alter the order of phases, that
needs to be spelled out in very bold letters. There be dragons, not the
only one is your recursive MACRO concerns.

Jens