- "We can get rid of that whole T' business" "But you like tea!" "No, we still have T, we just don't have T'"
Champion issue: #8374
Specification: https://github.com/dotnet/csharplang/blob/24aac29f7af589f5aa6242629642821df4cea422/proposals/collection-expressions-better-conversion.md
Following up from last time, we brought back the proposal with the requested tweaks for review by the LDM. The overall proposal is what we expected to see, and we will move forward with it.
With that out of the way, we then looked at the open question around how much we should prefer span types over other types. The existing wording of the rule, as shipped in C# 12, also makes
ReadOnlySpan<T>/Span<T> vs List<T> ambiguous, which is strong motivation for us to not solve that here; we have heard lots of feedback around the various aspects of collection expressions
that we needed to adjust, and this ambiguity has not come up among them. Further, given that this is ambiguity, it is an area that we will able to adjust in the future if we hear more feedback
around it, as we've done when we've adjusted other ambiguity rules in the past with betterness, better betterness, and bestest betterness. Additionally, API authors that have such an ambiguity
can make their APIs usable via OverloadResolutionPriorityAttribute in C# 13, by prioritizing the ReadOnlySpan/Span variant. Given this, we feel comfortable with the specification as written.
Specification is accepted as written.
Champion issue: #140
Spec: https://github.com/dotnet/csharplang/blob/d80d82e87e26412c2f5f3ef55c5253f474ad5049/proposals/field-keyword.md
Nullability proposal: #8360
Finally today, we took another look at the proposal for making the field keyword handle nullability automatically. Last time, we were leaning towards adopting the proposal, but hadn't quite
developed the unity we need to adopt the proposal, so we spent today talking through our reasoning more. The arguments are very similar to last time: is there too much magic going on here, or
is this something that users will expect to just work? One important argument that came up during this was a thought experiment to reorder field and nullable-reference types as features: if
we presume that field had existed before we did NRT, it would be nearly certain that this code would have existed. One goal of NRT was to allow perfectly safe and idiomatic code to continue
existing exactly as it had before with a minimal amount of changes. After more discussion on this point, we decided to move forward with the proposal, but will still need to dig into some of
the details. In particular, the tradeoff between "getters with no nullability warnings" or "getters that have more nullability warnings than when field starts as null"; this is the
difference between having a string unrelated = null; in the getter or not. We'll need to think through how complex we want to make our rules here; simpler rules are easier to explain, but
they might also still cause some confusion. We'll consider these details again in a future LDM.
General proposal is adopted. Specific behavior still needs more review.