- "That feels a bit like letting the wolf into the hen house."
Champion issue: #140
Spec: https://github.com/dotnet/csharplang/blob/d80d82e87e26412c2f5f3ef55c5253f474ad5049/proposals/field-keyword.md
Nullability proposal: #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
#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.
No conclusion today. Will revisit next week.
We next looked at whether we can scope field down to not being usable in events. 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.
Disallowed.
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.
We will keep the status quo: auto-set;-only properties are disallowed. Anything else is fair game.