# C# Language Design Meeting for August 14th, 2024

## Agenda

- [`field` keyword](#field-keyword)
    - [`field` nullability](#field-nullability)
    - [`field` in event accessor](#field-in-event-accessor)
    - [Scenarios similar to `set;`](#scenarios-similar-to-set)

## Quote of the Day

- "That feels a bit like letting the wolf into the hen house."

## Discussion

### `field` keyword

Champion issue: https://github.com/dotnet/csharplang/issues/140  
Spec: https://github.com/dotnet/csharplang/blob/d80d82e87e26412c2f5f3ef55c5253f474ad5049/proposals/field-keyword.md

#### `field` nullability

Nullability proposal: https://github.com/dotnet/csharplang/issues/8360

Today, we discussed a proposal for how nullable reference types could be handled for `field`. This proposal has a decent amount of magic in it, defining a new concept of "null-resilient getters", and
using that to determine whether the backing field should be considered nullable if it is not a value type. We have somewhat mixed feelings on this. The user code is ultimately something we think is
reasonable: `string Prop { get => field ??= ""; }` is a perfectly reasonable property definition. However, this is effectively a narrow case of the different backing field question, proposal
https://github.com/dotnet/csharplang/issues/133. The LDM has also expressed interest in that proposal, so the question we need to resolve is: does the nullability proposal move the cliff far enough to
warrant including the language? It certainly can't handle anything related to nullable value types, or anything related to `Lazy<T>` initialization. It will handle lazy initialization using `??=` or
`Interlocked.CompareExchange`, but the latter pattern is certainly not common outside of a few specific codebases. After discussion on this point, we have a slight lean towards nullability as proposed
in 8360, but this is a smaller LDM session and we don't feel that we have the unity to make a final call today. We'll let this ruminate in our brains for the weekend and then come back next week to
make a final decision.

##### Conclusion

No conclusion today. Will revisit next week.

#### `field` in event accessor

Question: https://github.com/dotnet/csharplang/blob/d80d82e87e26412c2f5f3ef55c5253f474ad5049/proposals/field-keyword.md#field-in-event-accessor

We next looked at whether we can scope `field` down to not being usable in `event`s. We don't see a use case; generally speaking, either the standard field-like events are sufficient, or the user
will want some kind of separate backing field, like a `List<Action>`, to store all the delegates so they can do something with them, rather than using `MulticastDelegate`. Absent scenarios, we
will not allow this.

##### Conclusion

Disallowed.

#### Scenarios similar to `set;`

https://github.com/dotnet/csharplang/blob/d80d82e87e26412c2f5f3ef55c5253f474ad5049/proposals/field-keyword.md#scenarios-similar-to--set-

Finally today, we considered whether to disallow scenarios that are _similar_ to, but not exactly, `{ set; }`. After some brief discussion, we think that we should keep with the status quo, and
only disallow `set;`-only properties. We don't want to try and get into the business of recognizing when a property does or does not have side-effects in the general case; it's either `set;`, which
is trivially vacuous, or it's something else, and we'll let the user do what they want.

##### Conclusion

We will keep the status quo: auto-`set;`-only properties are disallowed. Anything else is fair game.
