> From: Std-Proposals <std-proposals-bounces_at_[hidden].org> on behalf of Sebastian Wittmeier via Std-Proposals <std-proposals_at_lists.isocpp.org>

> https://godbolt.org/z/a5bceoexG

> So option A should work similar with F and X strings?

Ahh, sorry for the confusion - I should have made it clearer that it would have to generate a single R"(__LINE__)" by itself, because two f/x-strings do not concatenate as the proposal is written right now.

So no, that won't work.


> If instead of STRINGIFY(__LINE__) we were to put C++ code inside the STRINGIFY macro inside a {}, then the preprocessor would replace symbols and the C++ compiler would execute the code as it is inside {} of a F or X string?

Sorry, I don't really understand that question.

Right now, the proposal only supports an f/x-string as a single preprocessing-token before conversion: either an `X"..."` one, or an `F"..."` one; and there is no support for concatenation with any other string-literals. During conversion, it generates new tokens that replace the f/x-string.

If conversion happened inside the preprocessor, then we can do whatever I guess (within reason).

But today the preprocessor cannot concatenate two string-literal tokens into one, as far as I know, because conjoining them would form an invalid preprocessing-token.

It can concatenate a non-string with a string-literal token so long as the resultant is a valid preprocessing-token... which in practice is only true in some specific cases: such as if you concatenate a (non-string) `R` with a string-literal, or a `u8` with a string-literal, etc. I.e., if the conjoined result is a valid preprocessing-token.

-hadriel



Juniper Public