- "It's easy to dismiss as well, that's just math"
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.
Proposal will keep moving forward.
Next, we looked at the newest proposal for breaking change warnings. We had a few decisions we wanted to make here:
- Are the set of breaking change criteria generally reasonable?
- Do they apply to
field? - Are we ok with changing or removing the
latestlanguage 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.
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.