>
> 1. F"a={a" F"}"
>
> or
>
> 2. "a+b={a" F"+b}"
>
> or even
>
> 3. F"abs(a)={a" "bs(a)}"
>

Just glancing at this, I'd suggest staying as close as possible to WYSIWYG.
So #3 would just be two string fragments, and not result in an "abs" being
evaluated.
Especially with case 4.
This would also imply tokens that appear within "{}" pairs are broken up by
any intervening spaces, even if they aren't part of the literal.

IMO, having approached this problem before, I would prefer to just handle
F-string fragments like any other token, just with special considerations
for their contents later on.

On Wed, Oct 18, 2023 at 5:29 PM Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> The other question is, whether by themselves incomplete strings
> would/should work
>
>
>
> 1. F"a={a" F"}"
>
> or
>
> 2. "a+b={a" F"+b}"
>
> or even
>
> 3. F"abs(a)={a" "bs(a)}"
>
> and
>
> 4. the last example yes or no, even if abs is implemented as a macro?
>
>
>
> Jens pointed out that tokenization and macro expansion happen before
> string concatenation, so at the very least 4. would definitely not fit to
> the current phases. Probably 3. neither with the initially separated abs
> symbol.
>
>
>
> Would a F string count as a single token string literal or as several
> tokens or kind of both?
>
>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Tom Honermann via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Mi 18.10.2023 21:55
> *Betreff:* Re: [std-proposals] Supporting f-strings in C++: draft-R1
> *An:* std-proposals_at_[hidden];
> *CC:* Tom Honermann <tom_at_[hidden]>;
> On 10/17/23 2:19 AM, Hadriel Kaplan via Std-Proposals wrote:
>
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> <std-proposals-bounces_at_[hidden]> on behalf of Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> <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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>