"format" in $"{0:format}" should support interpolated-style or verbatim-style format

[kyoyama-kazusa]

Sometimes I want to use interpolated or verbatim strings at the format part in the interpolated strings, but the code is complicated. Therefore, this idea is born:
Allow the identifier $ and @ at the tail of the interpolated string, which means the format string part can be interpolated and verbatim.

The examples are:

string format = xxx ? "yyyy-MM-dd" : "yyyyMMdd";
string str = $"{someText:{format}}"$;
// Equals to
string str = string.Format($"{{0:{format}}}", someText);
// Or
string str = string.Format("{0:" + format + "}", someText);

string someText = ...;
string str = $"{someText}:hh\:mm\:ss\:fff"@;
// Equals to
string str = $"{someText}:hh\\:mm\\:ss\\:fff";

Thx!

[huoyaoyuan]

This was already possible from start, and relaxed by #1630 .

[333fred]

No, that issue is unrelated to this one. @Sunnie-Shine, I'm sorry but I have no idea what separates these strings from regular interpolated or verbatim interpolated strings. Could you elaborate?

[svick]

@333fred The examples confused me quite a lot too. If I understand it correctly, the goal is to modify how format strings behave in the following way:

1. Allow non-constant format string and alignment.

   Today, $"{someText,42}" compiles to string.Format("{0,42}", someText).

   If the alignment/padding size is not constant, you can do something like: string.Format($"{{0,{padLength}}}", someText), but that's quite awkward and doesn't take full advantage of interpolated strings. So the proposal is to allow $"{someText,{padLength}}"$ to achieve the same thing.

   The same approach would be used for format strings.

2. Allow verbatim format strings.

   I don't understand this part of the proposal. The verbatim "modifier" already affects the format string: $"{timeSpan:hh\\:mm\\:ss\\:fff}" and $@"{timeSpan:hh\:mm\:ss\:fff}" are equivalent and both compile to string.Format("{0:hh\\:mm\\:ss\\:fff}", timeSpan).

@Sunnie-Shine Did I represent your proposal accurately?

---

Personally, I can see the usefulness in allowing non-constant format string and alignment in interpolated strings, though I'm not convinced it could get over the "-100 points" hurdle. Also, I think the "$ at the end" syntax is clumsy and unnecessary: The syntax $"{someText,{padLength}}" is not valid today and so it could be used for this feature instead.

[kyoyama-kazusa]

@svick Yes! I mean this! This "clumsy" syntax is only for reference and can be modified during implementation. Although non-constant interpolated strings can be used rarely, this syntax is powerful sometimes, I think.

[kyoyama-kazusa]

@333fred I'm sorry for the wrong examples 😭 . In fact I means the pad length value (Using ,length syntax) and the format strings (:format syntax) disallows the non-constant values.
If I use non-constant value, there will be 2 cases to use: non-constant verbatim format and non-constant interpolated format. However, if the identifier @ is followed with the heading identifier $, that will be $@, which is equivalent to $@"...". Therefore, I put the identifier at the tail of the string.

[kyoyama-kazusa]

@huoyaoyuan I may not see the topic in that link >_<

[Frozenthia]

I don't like this for the simple reason that it would add more time to debugging and reading code.
I like that qualifiers of an expression would sit towards the head instead of the tail end of the expression. It states "The rest of this string that you see will be interpolated or verbatim."

I think this would also introduce some issues with Razor.

[kyoyama-kazusa]

@Frozenthia The only reason for why the identifier put on the tail of the string is that, the combination $@ is ambiguous (interpolated verbatim string, or interpolated string with verbatim format string).