Dot target-typed member access

[JesperTreetop]

With target-typed new as the latest example, there is an existing notion in the language of inferring the natural/effective/expected type from a location. If you're passing a parameter to a method, you can say new() and C# knows which type you mean; same with initializing or assigning to a variable or member.

So, with that in mind, how about also allowing .xyz to mean the member access of <inferred type>.xyz? This would allow making references to enum members and static members (factory methods, properties or constants for singleton/well-known instances) simpler, in cases where the type is already apparent or at least well-defined.

As an example, the following code:

_ = string.Compare("a0", "A０", CultureInfo.InvariantCulture, CompareOptions.IgnoreCase | CompareOptions.IgnoreWidth);

could instead be simply:

_ = string.Compare("a0", "A０", .InvariantCulture, .IgnoreCase | .IgnoreWidth);

There was a previous discussion involving this, but using a keyword before the dot/period. Since not using anything to trigger this would potentially change the meaning of any identifier anywhere, the previous discussion considered using var or default before the dot. But just using dot is not ambiguous or backwards incompatible - real_literals can start with dots, but they have to be followed by a digit, whereas identifiers can't start with digits. No legal program would change meaning or stop being legal.

[jnm2]

There is a proposal that is marked as championed (but assigned to a language design member who is no longer with the team): #2926

My understanding is that it would enable this syntax:

var r = string.Compare("a0", "A０", InvariantCulture, IgnoreCase | IgnoreWidth);

[JesperTreetop]

Yes, but wouldn't that potentially cause a lot of things to resolve in source-incompatible ways? (ie: what if InvariantCulture was a property on the class that method's in, and meant something different?)

[alrz]

My posterchild example for that #2926 (comment). I think it's easily resolvable for anything but overload resolution, but the team might be not interested in defining separate rules for it.

[JesperTreetop]

This comment by @gafter in another proposal highlights that there would be a syntactical conflict/ambiguity with the conditional member access operator (ie ?.) if one of these were to show up in a ternary expression. That's a real shame.

[TonyValenti]

I really like how something like this would enable me to quit typing things like '''ImmutableDictionary<string, SomeObject>.Empty'''.

Simply being able to type '''.Empty''' would be awesome.

[jnm2]

@TonyValenti #2926 gets around this by proposing that you would type Empty rather than .Empty.