From: Std-Proposals <std-proposals-bounces@lists.isocpp.org> on behalf of Sebastian Wittmeier via Std-Proposals <std-proposals@lists.isocpp.org>

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.

Yeah I think I'm leaning that way too. I think that most users will expect it to behave like simple textual transformation.

And I think most would expect that macros work - especially if some C-functions are actually implemented as macros, such as abs() and similar.

Plus I bet using __FILE__, __LINE__, __PRETTY_FUNCTION__, etc. will be done by plenty of people, and cause frustration when they don't work. (and there is no formatter specialization for std::source_location today either, fwiw)

---

If we do this in the preprocessor, then I think the easiest/cleanest way would be to make it similar to the unary _Pragma() operator.

But do we expect any of these to compile, and if so which ones?:

    1) X"a={a}" X"b={b}"

    2) X"a={a}"  "b={b}"

    3) "a={a}"  X"b={b}"

    4) F"a={a}" F"b={b}"

    5) F"a={a}"  "b={b}"

    6) "a={a}"  F"b={b}"

    7) F"a={a}" X"b={b}"

    8) X"a={a}" F"b={b}"

Deviations from the pattern shown in the table in [lex.string]p8 are likely to be considered surprising so should come with strong motivation.

That table suggests that 1-6 be well-formed, that each member of the sets of 1-3 and 4-6 have the same meaning, and that 7-8 are ill-formed.

Tom.

-hadriel



Juniper Public