[Proposal] implicit target-typed using static

[julealgon]

I'd like to propose a feature that would, based on the target type, automatically allow one to omit the class name prefix when accessing static members.

Here are a few examples:

public void Tint(Color color)
{
    // Do something here that is not relevant for the question
}

public enum Color
{
    Red,
    Green,
    Blue,
}

Normally, I can call the Tint method like this:

Tint(Color.Red);

Or I can opt into adding a static using to my file:

using static Color;

Tint(Red);

I propose this becomes possible by default, without adding the using static:

Tint(Red);

Based on the target-type and parameter position, the Color static type (or enum in this case) could be omitted.

This would work similarly with other constructs such as:

1. switch:

// `Color` is omitted since it can be inferred by the type of the `color` variable
return color switch
{
    Red => "Apple",
    Green => "Lemon",
    Blue => "Blueberry",
}

2. collection initialization:

// `Color` is omitted since it can be inferred by the explicit type of the element
IList<Color> colors = [Red, Green, Blue];

3. static method calls:

// `CultureInfo` is omitted since it can be inferred by the type of the argument
var text = string.Format(InvariantCulture, "something {0}", arg);

4. target-typed variables

string text = Empty;

If a member with the same name as the static member on the target type is present, that one wins. This would preserve backwards compatibility. In case of a conflict with an explicit using static, the member from the explicit using static wins as well.

I believe this would substantially simplify the language in the vast majority of cases and would be broadly applicable. The need for an explicit static using would be reduced or outright removed in a TON of scenarios.

I mentioned this idea here:

• Syntax to choose CurrentCulture/InvariantCulture for interpolated strings #3044 (comment)

As it would also apply to interpolated literals when needing to pass the CultureInfo object depending on the approach that is taken to support passing constructor parameters with interpolated literals.

[colejohnson66]

But why? What benefit does this serve if the desired outcome can already be achieved?

[julealgon]

The exact same behavior cannot be achieved today. By just leveraging using static you can get into situations where there are conflicts with other similarly named static members and you are forced to fully qualify. With this change, not only you don't need the using static most of the time, but it also allows you to use the same name in multiple different places at the same time with different meanings.

string emptyString = Empty; // string.Empty
Guid emptyGuid = Empty; // Guid.Empty

Each of the Empty above refers to a different member, but due to the target type being explicit, there is no ambiguity.

[ctigrisht]

this is just a massive breaking change, so many codebases will break

[julealgon]

Can you elaborate why/how this would be a breaking change with the constraints I outlined there?

If a member with the same name as the static member on the target type is present, that one wins. This would preserve backwards compatibility. In case of a conflict with an explicit using static, the member from the explicit using static wins as well.

There are probably scenarios I'm not considering but it would be great if you could list them so we can discuss how to avoid impact on existing code.

[TheUnlocked]

Would this be covered by #2926?

[julealgon]

Definitely sounds like it is! Looks like it is in the working set too which is awesome!

I tried searching for a few things before posting this but did not find that one.