czw., 19 paź 2023 o 11:36 Hadriel Kaplan via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
>
> Juniper Public
> > From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Chris Gary via Std-Proposals <std-proposals_at_[hidden]>
> > Date: Wednesday, October 18, 2023 at 8:22 PM
>
> > 1. F"a={a" F"}"
> > 2. "a+b={a" F"+b}"
> > 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.
>
> Yes, I think 2 is really hard and not even logical; and while 3 is do-able, we should probably not support that either - just to make the behavior consistent with not supporting 2.
>
>
> > 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.
>
> I'm not sure what you mean by that?
>
>
> > 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"a=" F"{}"
> X"a=" X"{}"
>
> 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"a=" COLOR_RED X"{a}" COLOR_RESET
>
> Imagine if those two 'COLOR_xxx' tokens are macros that resolve to some other X"" 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 _try_ 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_XSTRING, created by the programmer
> GEN_XSTRING("a=", COLOR_RED, "{a}", COLOR_RESET)
>

This is close to what I suggest, make string interpolation a build in
macro function, then many problems with interpretation will cease to
exists:
```
  F("a={COLOR_RED}{a}{COLOR_RESET}") // => "a={}{}{}", "\u001b[31m",
a, "\u001b[0m"
//or
  F("a=" COLOR_RED "{a}" COLOR_RESET) // => "a= \u001b[31m{}\u001b[0m", a
```
I will take a sequence of string literals (without comma in between)
and parse them, then output a reduced string literal and a list of
extracted tokens separated by comma.

> 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("a={}{}{}", COLOR_RED, a, COLOR_RESET);
>
> Or if they're ambitious and create a custom std::formatter:
>
> std::print("a={:red}", as_ansi(a));
>
> Which could then be:
>
> std::print(X"a={as_ansi(a):red}");
>
> -hadriel
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals