# C# Language Design Meeting for February 7th, 2024

## Agenda

- [Partial type inference](#partial-type-inference)
- [Breaking change warnings](#breaking-change-warnings)

## Quote of the Day

- "It's easy to dismiss as well, that's just math"

## Discussion

### Partial type inference

https://github.com/dotnet/csharplang/issues/1349  
https://github.com/dotnet/csharplang/pull/7582

We started today by looking at an Any Time proposal being worked on by a community member, @TomatorCZ, for partial type inference. He's been working on this proposal as
part of his master's thesis, and it's now at the point that LDM can take an initial look. One important thing that we wanted to establish was the motivation of the proposal.
We're not just trying to put `_` or `var` in more places; instead, what we're trying to do is ease the cliff between scenarios where the compiler can fully infer a type, vs
when it needs a bit of prodding to get the desired result. Thus, we are interested in the nested levels of type inference, because they allow the user to prod the compiler
into, for example, choosing a specific type of collection (`IEnumerable<T>` over `List<T>`) for a specific generic method, while not forcing the user to restate the element
type that is forced by some other input to the generic method.

One immediate concern, though, is that while this nesting of inference is very powerful, it could also lead to unbounded computation if not done carefully. The proposal has
been crafted with this in mind, as it is designed to ensure:

* Inference is bounded by the statement level. Statements cannot have inference effects on other statements except through lambda bodies, as can happen today.
* Inference cannot visit a single expression more than twice when calculating types.

This ensures that we aren't looking at a Hindley-Milner level of complexity, and hopefully helps keep the error scenarios constrained enough to offer good diagnostics. The
C# compiler already has some issues with giving good diagnostics in lambda scenarios, and we don't want to make it worse across the board by having non-local analysis failures.

Finally, we briefly considered the tooling aspect of this feature; like `var`, some users may wish to explicitly turn inference off, or turn it off unless the type inferred
is apparent. We think this is mostly a tooling problem, and that it should be solvable, though defining what "is apparent" will mean here may take some tweaking over time.

We're happy with this proposal as a starting point and want to keep working on it. It's not going to make C# 13, but we have high hopes for the proposal, and think it's heading
in the right direction. We'll tackle specific open questions and design points in later sessions.

#### Conclusion

Proposal will keep moving forward.

### Breaking change warnings

https://github.com/dotnet/csharplang/issues/7189  
https://github.com/dotnet/csharplang/issues/7918

Next, we looked at the newest proposal for breaking change warnings. We had a few decisions we wanted to make here:

1. Are the set of breaking change criteria generally reasonable?
2. Do they apply to `field`?
3. Are we ok with changing or removing the `latest` language version?

For the 1, we think we're ok with the criteria laid out here, but we do want to go even further: we'd like to have users be able to opt-in to warnings _after_ an upgrade, in
case they did not migrate using whatever garden-path approach we create. In other words, to apply to `field`, we'd like a warning after the user is on C# 13 for "there was a
`field` in scope that we're not binding to anymore, did you mean to do that?" warning.

Next, we looked at applying the criteria specifically to `field`. We didn't come to any hard conclusions here: there is some amount of verbal consensus that `field` would fit,
but we also do want to make sure that we're not holding the feature hostage for breaking changes any more than we already have.

Finally, we thought a bit about changing the `Latest` langversion. This ended up being a spirited discussion; there are ~6000 usages of the flag on GitHub, with a decent number
in internal repos as well. We're not entirely certain that changing it would meet the breaking change criteria we laid out in 1.

#### Conclusions

We're generally in favor of the criteria, but we want to look at post-upgrade opt-in warnings as well to help with non-linear upgrade paths as well.
