# C# Language Design Meeting for September 18th, 2024

## Agenda

- [Nullability in `field`](#nullability-in-field)
- [Extensions naming](#extensions-naming)

## Quote of the Day

- "Rename roles to frijoles"

## Discussion

### Nullability in `field`

Champion issue: https://github.com/dotnet/csharplang/issues/140  
Discussed proposal: https://github.com/dotnet/csharplang/issues/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: https://github.com/dotnet/csharplang/issues/5497
Rename proposal: https://github.com/dotnet/csharplang/blob/1e8255a438517bc3ad067c726c28cfa20cb60f1e/meetings/working-groups/extensions/rename-to-roles-and-extensions.md

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](../2023/LDM-2023-02-22.md#extensions) 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 class`es 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 extension`s; 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 extension`s, which is now just `extension`s, 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.
