Juniper Public
+AD4- From: Std-Proposals +ADw-std-proposals-bounces+AEA-lists.isocpp.org+AD4- on behalf of Chris Gary via Std-Proposals +ADw-std-proposals+AEA-lists.isocpp.org+AD4-
+AD4- Date: Wednesday, October 18, 2023 at 8:22 PM

+AD4- 1. F+ACI-a+AD0Aew-a+ACI- F+ACIAfQAi-
+AD4- 2. +ACI-a+-b+AD0Aew-a+ACI- F+ACIAKw-b+AH0AIg-
+AD4- 3. F+ACI-abs(a)+AD0Aew-a+ACI- +ACI-bs(a)+AH0AIg-

+AD4- Just glancing at this, I'd suggest staying as close as possible to WYSIWYG. So +ACM-3 would just be two string fragments, and not result in an +ACI-abs+ACI- being evaluated.

Yes, I think 2 is really hard and not even logical+ADs- and while 3 is do-able, we should probably not support that either - just to make the behavior consistent with not supporting 2.


+AD4- This would also imply tokens that appear within +ACIAewB9ACI- pairs are broken up by any intervening spaces, even if they aren't part of the literal.

I'm not sure what you mean by that?


+AD4- 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.

Except these:

    F+ACI-a+AD0AIg- F+ACIAewB9ACI-
    X+ACI-a+AD0AIg- X+ACIAewB9ACI-

We really should support concatenating two f-strings, or two x-strings, I think. One reason to do so is simply so people can break up long ones across multiple lines.

---
The challenging part is handling macros that resolve to f/x-strings, in such a sequence as:
    X+ACI-a+AD0AIg- COLOR+AF8-RED X+ACIAew-a+AH0AIg- COLOR+AF8-RESET
Imagine if those two 'COLOR+AF8-xxx' tokens are macros that resolve to some other X+ACIAIg- literals (like ansi color codes, for this example).
Since macro expansion happens in one pass left-to-right, and only after the previous tokens were expanded, then the above is non-trivial to handle. Possibly even unsafe to +AF8-try+AF8- to handle.
I can think of work-arounds, but only if the user invokes a function-like macro for them. For example:
    // using a variadic macro GEN+AF8-XSTRING, created by the programmer
    GEN+AF8-XSTRING(+ACI-a+AD0AIg-, COLOR+AF8-RED, +ACIAew-a+AH0AIg-, COLOR+AF8-RESET)
But at that point, why would they bother using this feature to begin with?? They could just do whatever they do today.
They could just do this for example:
    std::print(+ACI-a+AD0AewB9AHsAfQB7AH0AIg-, COLOR+AF8-RED, a, COLOR+AF8-RESET)+ADs-
Or if they're ambitious and create a custom std::formatter:
    std::print(+ACI-a+AD0Aew-:red+AH0AIg-, as+AF8-ansi(a))+ADs-
Which could then be:
    std::print(X+ACI-a+AD0Aew-as+AF8-ansi(a):red+AH0AIg-)+ADs-
-hadriel