LDM Notes for April 8th, 2026

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2026/LDM-2026-04-08.md

Agenda

• Target-typed static member access
  • Scope review and motivating examples
  • Dot or no dot
  • Initial rollout scope

[PaulMaget]

Still not convinced by this.
Adding too much syntactic sugar is dangerous and will frighten new programmers.

[CyrusNajmabadi]

is immediately more clear

It isn't for me. It's noise.

I've never used it in other languages, that may be why it still feels alien to me.

Millions of other users have. And have found it understandable. I get that it feels alien. But all new features feel that way. Since they are new. :)

In particular, the existing language feature scales very poorly here. With a lot of this redundancy being necessary within teh same expression. So the signal has a commensurate amount of noise that scales up with it.

For example, if i'm doing .GetField(...). i care about things like .Static and .Public. That is hte part that is important, and which immediately tells me what i'm getting. It is the true signal that is relevant. Having every | single | solitary | flag | that | is | passed now having a redundant and superfluous containing type that precedes it takes up 50% of the expression while not being actually relevant. That is not clarity to me.

[CyrusNajmabadi]

Though I'm still a bit scared

Go try it out and see :)

[PaulMaget]

It isn't for me. It's noise.

I guess it's the compromise between less language rules -> more verbosity vs more language rules -> less verbosity.
While one is not better than the other, being on this repo and following C# closely makes learning language rules easier than for a lot of people, this creates a bias toward the latter.
A lot of people want a language with a limited amount of rules that they can use in complex ways. While they might not be here, I don't think they should be neglected.

In any case I agree with what you're saying. I guess strict coding convention will be the way to limit the use of this feature to when it makes the most sens and doesn't add complexity.
We'll have to be careful of programmers who always prefer having to type less, even at the price of making their code harder to read for others.

[CyrusNajmabadi]

even at the price of making their code harder to read for others.

So, imo, this doesn't make the code harder to read. It elevates the important parts, while removing the redundant parts. So i think this is net win for many camps. Furthermore, this follows from virtually every 'type inferred'/'target typed' part of the language. You can always provide the tyeps for clarity, or eschew them when redundant. :)

[jnm2]

At the end of the day, this is not new territory. var let you omit a type name whenever you thought it was unnecessary to the reader. Target-typed new(...) did the same thing. .Xyz syntax joins them. These are options to be used in the best judgment of language users to hit a sweet spot for clarity. If the use of these features is unclear in a particular scenario, that is not necessarily because the features are bad features, any more than an unclear variable name is a sign that variables are a bad language feature. The onus is still on code writers to know their audience and to write clearly.

[sator-imaging]

I often declare the enum within a class.

public class MyClass
{
    public enum Options
    {
        Foo,
        Bar,
    }

    public void DoSomething(Options opts) { }
}

This proposal will allow omitting type name for the following case?

var x = new MyClass();
x.DoSomething(.Foo);  // Possible?

// Current: require full name
x.DoSomething(MyClass.Options.Foo);

[CyrusNajmabadi]

This proposal will allow omitting type name for the following case?

Yes.

[jnm2]

Just for completeness, I'll also mention that .Options.Foo will not be possible to write. Just .Foo.