Date: Thu, 19 Oct 2023 08:51:59 +0000
Juniper Public
+AD4- From: Std-Proposals +ADw-std-proposals-bounces+AEA-lists.isocpp.org+AD4- on behalf of Sebastian Wittmeier via Std-Proposals +ADw-std-proposals+AEA-lists.isocpp.org+AD4-
+AD4- Date: Wednesday, October 18, 2023 at 7:29 PM
+AD4- The other question is, whether by themselves incomplete strings would/should work
+AD4- 1. F+ACI-a+AD0Aew-a+ACI- F+ACIAfQAi-
The above will work, in my next proposed solution. Whether they +AF8-should+AF8- work I don't know. But it's actually easier to allow them than prevent them.
+AD4- 2. +ACI-a+-b+AD0Aew-a+ACI- F+ACIAKw-b+AH0AIg-
That one's tough because the first one is a plain string-literal.
I personally feel we should not need to support it - that an F+ACIAIg- or X+ACIAIg- prefix is not +AF8-only+AF8- an encoding indicator of its quoted-string.
That instead it's something more.
It's arguably also an +ACI-instruction+ACI- or even a macro invocation. So I don't think it's even logical to have a regular string-literal before an instruction, and expect the instruction to apply backwards.
+AD4- 3. F+ACI-abs(a)+AD0Aew-a+ACI- +ACI-bs(a)+AH0AIg-
That one can be made to work without too much difficulty. Again, whether it +AF8-should+AF8- work I don't know.
+AD4- 4. the last example yes or no, even if abs is implemented as a macro?
In my next proposal, where everything moves into preprocessing stage-4, it will work even if +AGA-abs()+AGA- is a macro. Ie., both 3 and 4 will semantically be equivalent to this, and resolve the +AGA-abs()+AGA- macro correctly:
F+ACI-abs(a)+AD0Aew-abs(a)+AH0AIg-
+AD4- Jens pointed out that tokenization and macro expansion happen before string concatenation, so at the very least 4. would definitely not fit to the current phases. Probably 3. neither with the initially separated abs symbol.
If we move everything into the preprocessor - which we would have to if we want macros to work inside the f/x-strings at all - then it can work. Because we'd have to perform some string-literal concatenation in the preprocessor anyway. And that concatenation would be done +AF8-before+AF8- the macros within the string get replaced (because the macros won't be replaced until they're pulled +AF8-out+AF8- of the string).
+AD4- Would a F string count as a single token string literal or as several tokens or kind of both?
We'd create two new preprocessing-tokens: an f-string-literal and x-string-literal. The lexer would generate those based on the F+ACIAIg- or X+ACIAIg-. So each is a single preprocessing-token.
During preprocessing expansion, the preprocessor would expand/replace those preprocessing-tokens with others (i.e., per the results of expansion).
>From a C+-+- TU perspective, after preprocessing those original F+ACIAIg- or X+ACIAIg- tokens won't exist, and neither will their quoted-string contents. The TU will only see the same stuff it sees today, including a string-literal format-string that was generated by the expansion of the F+ACIAIg- or X+ACIAIg-.
-hadriel
+AD4- From: Std-Proposals +ADw-std-proposals-bounces+AEA-lists.isocpp.org+AD4- on behalf of Sebastian Wittmeier via Std-Proposals +ADw-std-proposals+AEA-lists.isocpp.org+AD4-
+AD4- Date: Wednesday, October 18, 2023 at 7:29 PM
+AD4- The other question is, whether by themselves incomplete strings would/should work
+AD4- 1. F+ACI-a+AD0Aew-a+ACI- F+ACIAfQAi-
The above will work, in my next proposed solution. Whether they +AF8-should+AF8- work I don't know. But it's actually easier to allow them than prevent them.
+AD4- 2. +ACI-a+-b+AD0Aew-a+ACI- F+ACIAKw-b+AH0AIg-
That one's tough because the first one is a plain string-literal.
I personally feel we should not need to support it - that an F+ACIAIg- or X+ACIAIg- prefix is not +AF8-only+AF8- an encoding indicator of its quoted-string.
That instead it's something more.
It's arguably also an +ACI-instruction+ACI- or even a macro invocation. So I don't think it's even logical to have a regular string-literal before an instruction, and expect the instruction to apply backwards.
+AD4- 3. F+ACI-abs(a)+AD0Aew-a+ACI- +ACI-bs(a)+AH0AIg-
That one can be made to work without too much difficulty. Again, whether it +AF8-should+AF8- work I don't know.
+AD4- 4. the last example yes or no, even if abs is implemented as a macro?
In my next proposal, where everything moves into preprocessing stage-4, it will work even if +AGA-abs()+AGA- is a macro. Ie., both 3 and 4 will semantically be equivalent to this, and resolve the +AGA-abs()+AGA- macro correctly:
F+ACI-abs(a)+AD0Aew-abs(a)+AH0AIg-
+AD4- Jens pointed out that tokenization and macro expansion happen before string concatenation, so at the very least 4. would definitely not fit to the current phases. Probably 3. neither with the initially separated abs symbol.
If we move everything into the preprocessor - which we would have to if we want macros to work inside the f/x-strings at all - then it can work. Because we'd have to perform some string-literal concatenation in the preprocessor anyway. And that concatenation would be done +AF8-before+AF8- the macros within the string get replaced (because the macros won't be replaced until they're pulled +AF8-out+AF8- of the string).
+AD4- Would a F string count as a single token string literal or as several tokens or kind of both?
We'd create two new preprocessing-tokens: an f-string-literal and x-string-literal. The lexer would generate those based on the F+ACIAIg- or X+ACIAIg-. So each is a single preprocessing-token.
During preprocessing expansion, the preprocessor would expand/replace those preprocessing-tokens with others (i.e., per the results of expansion).
>From a C+-+- TU perspective, after preprocessing those original F+ACIAIg- or X+ACIAIg- tokens won't exist, and neither will their quoted-string contents. The TU will only see the same stuff it sees today, including a string-literal format-string that was generated by the expansion of the F+ACIAIg- or X+ACIAIg-.
-hadriel
Received on 2023-10-19 08:52:03