Runtime: Add FormattableString.CurrentCulture

[terrajobst]

We've told developers for a long time that they should be explicit about which cultures they use for formatting. In fact, we have FXCop rules like CA1305 that flag non-explicit use.

String interpolation in C# follows what virtually all our formatting APIs do unless instructed otherwise: it will format the string using the current culture. While we have FormattableString.Invariant, which allows customers to use the invariant culture, like so:

```C#
string text = FomattableString.Invariant($"This will be formatted using invariant {i}");

We don't have a way in string interpolation to explicitly indicate that we intend to use the current culture. This proposes an API to allow that. It would be a way to suppress FXCop rule CA1305.

### Proposal

```C#
namespace System
{
    public partial class FormattableString
    {
        // Existing API:
        // public static string Invariant(FormattableString formattable);

        public static string CurrentCulture(FormattableString formattable);
    }
}

Usage

C# // These are now equivalent string text1 = $"This will be formatted using current culture {i}"; string text2 = FomattableString.CurrentCulture($"This will be formatted using current culture {i}");

/cc @gafter

[gafter]

The point of having this API is that it would be a reasonable way to suppress FXCop rules like CA1305 by being explicit about the intention to use the current culture.

[terrajobst]

That's a good way to put it.

[nguerrera]

:+1: to the proposal and :-1: to the alternative. Anyone wishing to enforce the analysis, would not want bare $"..." to pass it. It is too terse to indicate any intent.

The reasonable use cases are:

• Disable the analysis if you don't care for it and blissfully use bare $"..."
• Enable the analysis and use this new API to help you get clean when you actually intend current culture.

[justinvp]

// These are now equivalent
string text1 = $"This will be formatted using current culture {i}";
string text2 = FomattableString.CurrentCulture($"This will be formatted using current culture {i}");

These would return the same result, but like FormattableString.Invariant, the latter allocates two more objects vs. the former ☹️ (an instance of FormattableString and the params object[]).

[terrajobst]

@nguerrera

:+1: to the proposal and :-1: to the alternative. Anyone wishing to enforce the analysis, would not want bare $"..." to pass it. It is too terse to indicate any intent

Fair point. I'll update the proposal to remove the alternative.

@justinvp

These would return the same result, but like FormattableString.Invariant, the latter allocates two more objects vs. the former ☹️

Quite frankly, I'm not sure we care that much. Formatting using the normal BCL APIs isn't very performant already (all arguments are boxed, the interaction between CultureInfo and formatters isn't ideal etc).

That alone wouldn't be a reason to punt this.

[justinvp]

Formatting using the normal BCL APIs isn't very performant already (all arguments are boxed, the interaction between CultureInfo and formatters isn't ideal etc).

This is an area I'd like to see improve. Internal optimizations can be made to address much of the existing overhead and new generic overloads could be added to avoid boxing for common cases. This is being discussed in dotnet/runtime#14484.

It's unfortunate that using FormattableString.Invariant/CurrentCulture to be explicit requires extra unnecessary overhead, especially if analyzers are recommending/encouraging it.

[terrajobst]

We agreed that the syntax with explicit culture (invariant or current) isn't ideal, but that's for the language teams to decided whether that's important to fix. We believe exposing the new API allows static code analysis tools to detect the case (i.e. establish the IL encoding of interpolated strings).

[mikhailshilkov]

I'll grab this one for hackathon today, looks good a the first issue