# C# Language Design Meeting for August 21st, 2024

## Agenda

- [Better conversion from collection expression](#better-conversion-from-collection-expression)
- [`field` keyword nullability](#field-keyword-nullability)

## Quote of the Day

- "We can get rid of that whole T' business" "But you like tea!" "No, we still have T, we just don't have T'"

## Discussion

### Better conversion from collection expression

Champion issue: https://github.com/dotnet/csharplang/issues/8374  
Specification: https://github.com/dotnet/csharplang/blob/24aac29f7af589f5aa6242629642821df4cea422/proposals/collection-expressions-better-conversion.md

Following up from [last time](LDM-2024-08-19.md#better-conversion-from-collection-expression), 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.

#### Conclusion

Specification is accepted as written.

### `field` keyword nullability

Champion issue: https://github.com/dotnet/csharplang/issues/140  
Spec: https://github.com/dotnet/csharplang/blob/d80d82e87e26412c2f5f3ef55c5253f474ad5049/proposals/field-keyword.md  
Nullability proposal: https://github.com/dotnet/csharplang/issues/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.

#### Conclusion

General proposal is adopted. Specific behavior still needs more review.
