Skip to content

Latest commit

 

History

History
73 lines (54 loc) · 5.86 KB

LDM-2024-09-18.md

File metadata and controls

73 lines (54 loc) · 5.86 KB
Raw

C# Language Design Meeting for September 18th, 2024

Agenda

Quote of the Day

  • "Rename roles to frijoles"

Discussion

Nullability in field

Champion issue: #140
Discussed proposal: #8425

We started today by looking at how we're going to deliver nullability rules for the field preview that ships in November with .NET 9. While we still want a full inference system, we don't think that we reasonably have time to implement it before the first preview goes out. Therefore, we need to plan what our initial preview will ship with for options. We have:

  1. No special support. To suppress nullability warnings, = null!; will be required.
  2. Support for the nullability attributes with the field attribute target, allowing a user to mark the backing field as [field: MaybeNull, AllowNull].
  3. Leave the backing field oblivious, and do not report nullability warnings on it for now.

After some discussion, we like option 2. Both option 1 and 2 do leave some cruft for the user to clean up after we have inference, but option 1 leaves the code in a potentially unsafe state; option 2 is planned to be supported in the inference scenario anyways, and it leaves the user's code in a safe state. Option 3 doesn't leave any cruft, but it does mean that users will be operating in a null-unsafe state before they get the new warnings.

Conclusion

We will attempt to ship option 2, support for field-targeted nullability attributes. If we do not have enough runway however, we will end up shipping 1 by pure virtue of it requiring no additional compiler work.

Extensions naming

Champion issue: #5497 Rename proposal: #8431

Finally today, we are reopening the topic of naming for the feature that has alternately been known as "shapes", "roles & extensions", and now "extensions". When we previously settled on the implicit extension and explicit extension, we felt that we'd reached a breakthrough; this was a name and category system that jibed well with the LDT, and we felt it added clarity and would help explain this feature to customers. However, now that we've had a year and a half to use this name with the broader C# community, we no longer feel that this connection adds clarity to the feature; most of us feel that some kind of different noun for explicit extension would be better. One example where some of us find issue: naming conventions for these types. Many existing static classes that are used for extension methods are named something like ArrayExtensions, and while such a convention works just fine for implicit extension types, we're not convinced that would work well for explicit extensions; we think of those as something like Person, not JsonObjectPersonExtension or the like. And by tying these features to the same noun, we then imply that these naming conventions should be related. These types of ties continue throughout the feature, and a read of the room after this discussion was particularly telling; the vast majority of the LDT thought that separate nouns was the correct path. A couple of members were unsure, and no one was convinced that a single noun + modifier was the correct path forward. Given this, we will plan on going back to separate nouns. Of course, that then immediately opened the floor for which noun to use. We're not ready to make decisions on nouns today, but we did brainstorm a list to do some initial preferencing:

  • role - The original proposal. We like that it's clear that the underlying object is assuming a "role"; it's all it was before, but more specific. Some members do have a gut feeling that there's something wrong with it, but haven't yet been able to put it into words.
  • adapter - Lots of initial dislike for this one. Adapter as a pattern implies that maybe you could use it to adapt one class to be another, which this feature will not allow.
  • alias - This doesn't imply anything about the additive nature of the feature, which feels like a bit of a misstep.
  • view - This one is also decently well-liked, but there's some concern that the word view is already too overloaded, even within the .NET ecosystem. Database views, our various UI frameworks, etc; it gives us pause that we'd be able to explain this well, which is the concern that brought us back here in the first place.
  • shape - This one has a lot of previous baggage around implicit implementation, and we don't want to imply that we're introducing generalized structural typing to C#.
  • extension type - Very wordy. It does relate to what was previously known as implicit extensions, which is now just extensions, but as discussed previously, we're not sure that's a benefit.
  • layer - Wasn't discussed in depth, no one had strong feelings on this one.
  • facade - Wasn't discussed in depth, no one had strong feelings on this one.
  • abstraction - Wasn't discussed in depth, no one had strong feelings on this one.
  • augmentation/augment - This is what F# calls their extension methods, though they don't use it as a keyword. We're a bit wary of conflating that.
  • intent - This makes some people think of Android first, rather than a type system thing.

Of these, we had 2 clear standouts during initial preferencing: role, with most of the LDM liking it, and view, with a majority at least being ok with it, but not as many liking it as role. We'll let this one sit for a couple of weeks, and then come back with more thoughts.

Conclusion

The general idea is approved. implicit extension is now just extension. We don't yet have a name for explicit extension, but role is a standout leader, with view being another possible contender.