Beside the possible inside string concatenations in the {} blocks, we have the outside string concatenations.   Those could be implemented in two ways (if at all):   Either only 'complete' strings can be concatenated, e.g. a normal string prefixed or postfixed to an F string, or two complete F strings concatenated together (as if the format string would be concatenated, and both sets of parameters provided in order, but possibly only supporting those formats, where the result is the same as interpolating both F strings separately and concatenating the result, so no referral to the other's format string's parameters.   Or F strings can be built together out of parts. Which is more like Option A from my list. So each F string would not have to be complete by itself, e.g. opened curled braces could be closed in another F string, with which it is concatenated.   I think both of the last two options have some intuitiveness about them.     But overall, I was arguing for rather better (and less surprising) support of the preprocessor, as otherwise it could lead to hard to find bugs.   I have done as part of some projects ActionScript programming more than a decade ago, where code could be put into MXML (a XML GUI description) attributes with HTML escaping. Reminds me of it. Sometimes you needed escaping, sometimes not.   Each additional rule - change of preprocessor support compared to normal code, only sometimes are outer parantheses required, any common characters, which need escaping - will be a major pain point for users.   -----Ursprüngliche Nachricht----- Von:Jens Maurer <jens.maurer_at_[hidden]> Gesendet:Mo 16.10.2023 19:32 Betreff:Re: [std-proposals] Supporting f-strings in C++: draft-R1 An:std-proposals_at_[hidden]; CC:Sebastian Wittmeier <wittmeier_at_[hidden]>; On 16/10/2023 18.54, Sebastian Wittmeier via Std-Proposals wrote: > So the solution for option E with preprocessor support could be > > [Phases: https://eel.is/c++draft/lex.phases ] > > In Phase 3, when the decomposition into preprocessor tokens happens, the F or X string could be parsed and decomposed into a macro call with reordering of the format string and the {} parameters. > > [Separation into preprocessing tokens: https://eel.is/c++draft/lex.pptoken ] > > In Phase 4 that internal macro would create a call to std::format for F strings and a comma separated list for X strings and all other macro calls and preprocessor symbol expansions are done for the (previously curly embraced {} ) parameters. So, you can't create an F string by string concatenation?  That feels surprising. Jens >   > >     -----Ursprüngliche Nachricht----- >     *Von:*Jens Maurer <jens.maurer_at_[hidden]> >     *Gesendet:*Mo 16.10.2023 17:19 >     *Betreff:*Re: [std-proposals] Supporting f-strings in C++: draft-R1 >     *An:*std-proposals_at_[hidden]; >     *CC:*Sebastian Wittmeier <wittmeier_at_[hidden]>; >     On 16/10/2023 15.47, Sebastian Wittmeier via Std-Proposals wrote: >     > How do F strings react, when they are concatenated out of different types of strings? Does each F one of them have to be complete? Or can a F be mixed with a normal string and the concatenation has to be complete? > >     I'd like to point out that preprocessor tokenization happens in phase 3, >     macros are expanded in phase 4, and strings are concatenated in phases 5 and 6. >     See [lex.phases] for details. > >     In which phase are these F or X strings supposed to be turned into >     something else that presumably ends up as a phase 7 C++ expression >     performing some formatting when evaluated? > >     Jens > >