# C# Language Design Meeting for June 9th, 2025

## Agenda

- [Extensions](#extensions)

## Quote of the Day

- "It really feels like a Monday morning"

## Discussion

### Extensions

Champion issue: https://github.com/dotnet/csharplang/issues/8697  
Specification: https://github.com/dotnet/csharplang/blob/435111275ae5f8f949cbfa9c918645738ccf38a0/proposals/extensions.md#cref

Today, we followed up on the cref questions from [last time](LDM-2025-06-04.md#cref-references), after the working group took another look at
the area. An unfortunate detail here is that the skeleton implementation keeps surfacing: we try to paper over the implementation details for
users, but in areas where it bleeds through, particular groups will likely need to understand the difference between the actual
implementation of the extension member and the skeleton that exists to inform the language about the structure. This is true for anything that
wants to interact with real structures, including both documentation comments and other things like reflection. After extensive discussion,
we don't think there's a way around this in the end, particularly given our desire to keep `ExtensionType.Method` references working for
existing `cref`s to extension methods in the new form. Another argument in favor is that doc comment XML does not reflect the structure
of C#; it reflects the structure of metadata. Any tooling interacting with doc comment XML today already needs to know about the structure
of metadata and how to map it back onto C# structure for output, and this would be no different. Therefore, we approve the following decisions
today:

* There will be one syntax to refer to extension skeleton members: `ExtensionType.extension(type).Member`. We will not offer "reduced" forms
  such as `type.Member` in `cref`s in the language for simplicity.
* There will be one syntax to refer to extension implementation members: `ExtensionType.Member`. This will work for methods and things that
  reduce into methods, such as `E.extension(int).Prop` and `E.get_Prop`/`E.set_Prop`.
* Extension blocks themselves are not able to be referred to at this time. `E.extension(int)`, on its own, is not a valid `cref` location.
  We have no examples of where we'd actually want to do this and currently think that it would not be a good idea to expose this concept,
  as extension blocks are not named entities in and of themselves in C#.

This last point ended up being somewhat contentious, as we intend to allow `param` elements to be documented on the extension block itself.
Do users expect to be able to write other documentation comments in that same area and have them reflected somewhere? Where would users
assume such comments live? On the block itself, or on the members inside the block? We think conceptually we want to reinforce the idea that
extension parameters and type parameters are copied to the members themselves, not to the block, and the same will extend to documentation on
them.

#### Conclusion

The proposed `ExtensionType.extension(Type).Member` syntax is approved. Implementation members will be referenceable using
`ExtensionType.Member`. Extension blocks are not referenceable entities.
