On 10/17/23 2:19 AM, Hadriel Kaplan via Std-Proposals wrote:
>> From: Std-Proposals<std-proposals-bounces_at_[hidden]> on behalf of Sebastian Wittmeier via Std-Proposals<std-proposals_at_[hidden]>
>> 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
<http://eel.is/c++draft/lex.string#8> 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