Proposal: Add syntax support to CurrentCulture/InvariantCulture for interpolated strings #177

iam3yal · 2017-02-24T11:54:14Z

iam3yal
Feb 24, 2017

Disclaimer: I've copy/paste this from #12336 but did some modifications.

Summary

Add syntax support to CurrentCulture/InvariantCulture for interpolated strings.

Motivation

C# introduced interpolated string but with no obvious way to decide which CultureInfo to use during formatting.

Currently it is possible to use InvariantCulture like this:

FormattableString.Invariant($"count: {count}")

This requires code to target .NET 4.6 and allocates the FormatabbleString instance instead of just generating call to string.Format.

Detailed design

This could be improved by adding prefixes to explicitly choose CultureInfo like this:

$C"count: {count}"    // This will call string.Format with CultureInfo.CurrentCulture
$@C"count: {count}"   // Same as above for verbatim string literals 
$I"count: {count}"    // This will call string.Format with CultureInfo.InvariantCulture
$@I"count: {count}"   // Same as above for verbatim string literals

This will compile to string.Format and will not require targeting .NET 4.6.

Additionally, it will be easy to add analyzer to enforce setting the C and I prefixes always, like we have now in FxCop for string.Format and others.

p.s. I think that capital letters standout better but maybe lowercase letters might be slightly easier to type.

dlemstra · 2017-04-25T13:17:16Z

dlemstra
Apr 25, 2017

I like what is done in ECMAScript 6 and I would like to purpose a slightly different syntax than what is written above. How about the following syntax (with a backtick instead of the $):

C`count: {count}`    // This will call string.Format with CultureInfo.CurrentCulture
@C`count: {count}`   // Same as above for verbatim string literals 
I`count: {count}`    // This will call string.Format with CultureInfo.InvariantCulture
@I`count: {count}`   // Same as above for verbatim string literals

This syntax will also make is easier to use a quote inside the string because you no longer need to replace them:

@`<html>
<div data-count="{count}"/>
</html>`

0 replies

HaloFour · 2017-04-25T13:45:00Z

HaloFour
Apr 25, 2017

@dlemstra

String interpolation already uses $ in C#, I don't think it makes any sense to incorporate a second syntax borrowed from another language.

0 replies

alrz · 2017-04-25T13:57:45Z

alrz
Apr 25, 2017

On syntax, the leading $ is mainly used for lexer to expect an interpolated string. culture invariance could be also an optional suffix e.g. $@"{e}"i since it would not affect lexer.

0 replies

jnyrup · 2017-05-11T06:59:14Z

jnyrup
May 11, 2017

@dlemstra from The C# Programming Language

In the early days of the C# language design, we experimented
with using the backtick (`) character. Personally, I really liked this choice: The backtick
is in the quote family and is a grossly underused character. In fact, it was so underused
that some international keyboards don’t even include a key for it. We were lucky to
have such a good, early international following for C#, which allowed us to fix this
potential error very early in the design of the language.
-- Brad Abrams

I can type a backtick on my keyboard (Danish QWERTY) but it is a dead key which means I have to type Shift+[backtick key], Space to get a backtick -- or a grave accented whitespace.

This most likely takes the prize as the common programming character most difficult for me to type.

0 replies

orthoxerox · 2017-05-11T08:29:14Z

orthoxerox
May 11, 2017

@alrz implementing the flag as a postfix will affect the most important lexer, the human lexer 😀. If your string is long enough you'll have to scan till its end to find out if the treatment is invariant. It can already be annoying with regexps, but regexps are (usually) short enough for this to work.

0 replies

jnm2 · 2017-05-11T16:01:47Z

jnm2
May 11, 2017
Collaborator

Yeah, I like the prefix $i best.

0 replies

dstarkowski · 2017-05-12T09:16:52Z

dstarkowski
May 12, 2017

@orthoxerox

implementing the flag as a postfix will affect the most important lexer, the human lexer 😀. If your string is long enough you'll have to scan till its end to find out if the treatment is invariant. It can already be annoying with regexps, but regexps are (usually) short enough for this to work.

Does it really require to 'scan' the string? I'd rather say peek at the end of line ;)

Regex is a reason why I like the idea of postfix. People may be used to this and expect modifiers to be at the end. Also $i@"..." looks a bit crowded for me.

0 replies

iam3yal · 2017-05-14T12:55:25Z

iam3yal
May 14, 2017
Author

@dstarkowski

Do you mean $@i? because atm the syntax for interpolated strings is $ and $@ but I really find it straightforward, also, I'd prefer to have a crowded syntax than to scan or peek at the end what I can see at glance but that's just me. :)

Just because we have modifiers for numbers and regex at the end that in many cases tend to be short doesn't mean we need to follow the same pattern here.

0 replies

jnm2 · 2017-05-14T17:16:10Z

jnm2
May 14, 2017
Collaborator

@eyalsk I'd prefer $i@ because the i modifier is modifying the $ and the @ is completely orthogonal to them. (Welcome back, long time no see!)

0 replies

rikimaru0345 · 2017-06-01T03:38:18Z

rikimaru0345
Jun 1, 2017

I don't know if adding more prefixes solves anything.
It makes the code very hard to read.

There's also another problem that has to do with localization.

No change: string.Format("You have {0} things", count);

With localization support string.Format(L("You have {0} things"), count); where L() is a function that does a simple dictionary lookup.

And with $"You have {count} things" that is not possible anymore.
There should be a way to get/pass the format-string to a function.

Of course FormattableString can solve this as well, but also suffers from the drawback of allocating at least one object.

I have a feeling that both problems can be solved in the same way.
Maybe the real issue here is just that FormattableString is not efficient enough.
Do you agree?

0 replies

jnm2 · 2017-06-01T03:58:26Z

jnm2
Jun 1, 2017
Collaborator

@rikimaru0345 The other really good use case for $i"Foo {foo}" is that they would be able to be const string literals.

0 replies

rikimaru0345 · 2017-06-01T04:12:19Z

rikimaru0345
Jun 1, 2017

Maybe the following could solve the performance problems easily and in a fully backwards compatible way. The same code that decides whether to generate FormattableString or a string.Format call could be used to also potentially generate this:

Compile $"Person: {name}, Age: {years}" to

struct FormatStringStronglyTyped
{
public readonly string Format;
public readonly string Arg1;
public readonly int Arg2;
}

Auto implement Deconstruct as well
Use tuple deconstruction and projection to call a method that has multiple parameters.

Now you can easily write a method that takes all those parameters from the deconstruction and provide your own formatter like this:

MyFormattingFunction($"Person: {name}, Age: {years}") // Will use deconstruction + projection to deconstruct directly into the parameters of MyFormattingFunction

string MyFormattingFunction(string format, string arg1, int arg2) => string.Format(format, arg1, arg2); // Can set culture settings here, as well as a language localization lookup for 'format'

Does that idea make sense?

@jnm2 Unfortunately I don't know what can be done about const string literals.
Wouldn't that need to evaluate string.Format() at compile time?

0 replies

jnm2 · 2017-06-01T04:25:51Z

jnm2
Jun 1, 2017
Collaborator

@rikimaru0345 Yes, which is fine if all inputs are constants and the culture is invariant.

0 replies

iam3yal · 2017-07-13T09:41:11Z

iam3yal
Jul 13, 2017
Author

@jnm2 Yup I'm up for whatever syntax tbh as long as they will add it.

p.s. Thanks, been busy with some projects and uni so I'm less active. 😉

0 replies

DmitryMak · 2024-05-31T00:28:13Z

DmitryMak
May 31, 2024

Allowing shorter symmetrical syntax would be nice from Globalization analyzer perspective: dotnet/runtime#88902

0 replies

stephentoub · 2024-05-31T14:19:27Z

stephentoub
May 31, 2024
Collaborator

C# introduced interpolated string but with no obvious way to decide which CultureInfo to use during formatting.
Currently it is possible to use InvariantCulture like this:
FormattableString.Invariant($"count: {count}")
This requires code to target .NET 4.6 and allocates the FormatabbleString instance instead of just generating call to string.Format.

The string.Create method let's you specify a culture, e.g.

string result = string.Create(CultureInfo.InvariantCulture, $"count: {count}");

It utilizes the interpolated string handlers support introduced in C# 10, where the only allocation here will be for the resulting string.

0 replies

DmitryMak · 2024-05-31T19:24:17Z

DmitryMak
May 31, 2024

@stephentoub I think the current state is not compatible with Globalization rules. Analyzers have to ignore interpolated strings because there is no way to specify the culture explicitly there. Users just have to know that CurrentCulture is used by default and analyzers have to assume it was intentional. I think it is a bit of a gotcha for new users and goes against the goal of the Globalization analyzers (at least as I understand them).

Aside from analyzers, just ergonomically, it feels very strange to have such an asymmetric (for lack of a better word) syntax:

string result = $"count: {count}";
string result = string.Create(CultureInfo.InvariantCulture, $"count: {count}");

Invariant syntax feels very verbose. Is the assumption that the code that wants to use InvariantCulture should just set CurrentCulture to InvariantCulture (via e.g. Thread.CurrentCulture or System.Globalization.Invariant)?

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Proposal: Add syntax support to CurrentCulture/InvariantCulture for interpolated strings #177

{{title}}

Replies: 17 comments

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Select a reply

Proposal: Add syntax support to CurrentCulture/InvariantCulture for interpolated strings #177

Summary

Motivation

Detailed design

Replies: 17 comments

jnm2 May 11, 2017 Collaborator

iam3yal May 14, 2017 Author

jnm2 May 14, 2017 Collaborator

jnm2 Jun 1, 2017 Collaborator

jnm2 Jun 1, 2017 Collaborator

iam3yal Jul 13, 2017 Author

stephentoub May 31, 2024 Collaborator

jnm2
May 11, 2017
Collaborator

iam3yal
May 14, 2017
Author

jnm2
May 14, 2017
Collaborator

jnm2
Jun 1, 2017
Collaborator

jnm2
Jun 1, 2017
Collaborator

iam3yal
Jul 13, 2017
Author

stephentoub
May 31, 2024
Collaborator