# C# Language Design Meeting for June 30th, 2025

## Agenda

- [Type parameter inference from constraints](#type-parameter-inference-from-constraints)
- [Target-typed static member lookup](#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.
