C# Language Design Meeting for August 14th, 2024

Agenda

• field keyword
  • field nullability
  • field in event accessor
  • 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 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.

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.