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@juniper.net>
Gesendet: So 15.10.2023 18:45
Betreff: Re: [std-proposals] Supporting f-strings in C++: draft-R1
An: std-proposals@lists.isocpp.org;
CC: Sebastian Wittmeier <wittmeier@projectalpha.org>;
> From: Std-Proposals <std-proposals-bounces@lists.isocpp.org> on behalf of Sebastian Wittmeier via Std-Proposals <std-proposals@lists.isocpp.org>

> 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