C# Language Design Meeting for June 30th, 2025

Agenda

• Type parameter inference from constraints
• Target-typed static member lookup

Quote(s) of the Day

• "You need to get better at ventriloquism"
• "When you said messy field, were you referring to the field keyword?" "I was seeing if anyone would stoop that low"

Discussion

Type parameter inference from constraints

Champion issue: https://github.com/dotnet/csharplang/issues/9453
Specification: https://github.com/dotnet/csharplang/blob/746d354ce523385ab4f36a94792d4acd64f3b531/proposals/type-parameter-inference-from-constraints.md

We started today by looking at a proposed breaking change for C#: allowing the type inference phase to use constraints when doing type inference. This is a longstanding community request that has been previously rejected due to the risk of breaking changes. However, we feel that in the time since it was rejected, other breaking changes in similar areas, most closely the lambda/method group natural type change in C# 10, have given us a blueprint for how to proceed here. In particular, long preview periods will be essential in collecting comprehensive examples of where the breaks will end up happening. In particular, this is an area where we don't have great tools to find potential breakage today, as this is not something that is easily searchable via regex. That being said, we are unanimously in support of moving forward with this change, and look forward to seeing it in a future version of C#. Future meetings will need to review the exact rules being proposed, as we did not get into the nitty gritty of type inference dependency changes today.

Conclusion

Approved in principle, into the working set.

Target-typed static member lookup

Champion issue: https://github.com/dotnet/csharplang/issues/9138
Specification: https://github.com/dotnet/csharplang/blob/746d354ce523385ab4f36a94792d4acd64f3b531/proposals/target-typed-static-member-lookup.md

Next and last, we looked at another new proposal: target-typed static member lookup. This one is more controversial, both in the community and in the LDM itself. There's definite tension around a few points:

• How far do we want to take this? There are various cut points we could consider, such as enum members, properties, methods, etc. The more permissive we are, the greater the chance for this to be used to make unreadable code. On the other hand, there are legitimate use cases that we would also like to support. For example, union types may want to be able to infer methods from their containers for creation. We think we need more examples here; both good and bad. This is a gut feeling area, and while we can look to some adjacent ecosystems for inspiration, such as Swift and Dart, ultimately we need to make the decision about what is best in C#.
• What type of sigil should we use, or should we not use a sigil at all? Again, contemporaries here seem to use . as the sigil, and there are some definite benefits to using a discrete sigil. It would ensure that we can't run into Color Color problems where we would have to decide whether Color is target-typed member access, or a reference to the type named Color, or a reference to the member in the current type named Color. This area is already complex for both humans and compilers, and making it more so is concerning. One analogy we liked during the meeting was an analogy to new(): when you remove the type from expression, new() is what remains. Similarly for this feature, when you remove the type from the expression, .Member is what remains. We also considered the _. syntax as an additional option, but it got no real support after initial suggestion.

After some lively debate on this subject, we are moving forward on this topic, with most of the LDM preferring an explicit sigil in ., a small contingent preferring to not take the feature, and a general need to see more examples and think through the impact they will have further.

Conclusion

Topic is moved to the working set, will continue to be reviewed further.