Hi Hadriel, I really have not known, whether it was working with the preprocessor, without reading up and trying out.   I think that topic belongs slightly together with the escaping/delimiter discussion and there are five basic options to activate the preprocessor:   A) Each (or only the more complex) C++ expression leave the F string and resume it, everything is concateated, e.g.:     print( X"SOME_FLAG = {" SOME_FLAG ":x}" );     - easier to include the preprocessor without preprocessing time parsing     - proliferation of quotes/unquotes     - looks more like the iostream way, when we add + or even << in between   B) simple specific escaping     print( X"SOME_FLAG = { ####SOME_FLAG####:x }" );     - the part between #### #### is handled by the preprocessor, although it is within a X/R string     - also helps with colon     - possible to forget for generic code, except if #### required for all {} expressions, e.g. a l-value identifier could be a preprocessor redefined symbol     - so either it is required every time (no simple {lvalue} possible anymore) or it is only used, when needed and will be often forgotten or other code changes (SOME_FLAG is suddenly a preprocessor define) that would require it   C) complete escaping     print( X"SOME_FLAG = { a ? \"\\\\\" \\: \"\\:\" :x }" ); // for a ? "\" : ":"     - certain characters are escaped: '"', '\', '}', ':'     - not easy to read     - better (?) than heuristics with additional paranthesis, which only sometimes work   D) Flexible escaping similar to raw string literals     print( X"SOME_FLAG = {dch{ a ? b : c :dchx }dch" );     - with dch a delim character sequence, which can be freely chosen           E) have the preprocessor parse the string itself     print( X"SOME_FLAG = { SOME_FLAG:x}" );     - most difficult to sync WG21/WG14   -----Ursprüngliche Nachricht----- Von:Hadriel Kaplan <hkaplan_at_[hidden]> Gesendet:So 15.10.2023 18:45 Betreff:Re: [std-proposals] Supporting f-strings in C++: draft-R1 An:std-proposals_at_[hidden]; CC:Sebastian Wittmeier <wittmeier_at_[hidden]>; > From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> > you write that there is no preprocessor support within the f-strings. > Is it possible to concatenate preprocessor macro results with preprocessor string concatenation? > If yes, would it be further possible to have the preprocessor preprocess code in its usual way, put it through a STRINGIFY macro and concatenate it into the f string? You can use preprocessor macros to stringify other macro expansions as you can do today, of course - but as far as I know the preprocessor cannot concatenate two string literals into one token literal using the `##`. It's usually the phase-6 translation right afterwards that concatenates them instead. So then I don't see how you'd get it to become an f-string, since presumably you'd want to join multiple stringified literals into one final f-string. For just _one_ stringified macro I think you can do it, but that doesn't seem useful. I.e., you might be able to get a stringified `__LINE__` for line 42 to become a `F"42"`, but if you wanted it to become `F"{42:x}"` instead, I don't think that's possible. (though I'm no PP expert) I mean basically think of the `F"..."` or `X"..."` as being similar to `R"(...)"` in terms of tokens, and you can try to create an `R"(...)"` using the preprocessor today to see if it's possible - I don't think it is, but I might be wrong. If it _is_ possible then it should be possible to do for f-strings too. --- Or maybe I misunderstand you - are you instead saying: "I know macro-magic won't work with f-strings as defined, but can the proposal define some way for it to work?" -hadriel Juniper Public