meetings/2025/LDM-2025-06-09.md
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, 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 crefs 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:
ExtensionType.extension(type).Member. We will not offer "reduced" forms
such as type.Member in crefs in the language for simplicity.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.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.
The proposed ExtensionType.extension(Type).Member syntax is approved. Implementation members will be referenceable using
ExtensionType.Member. Extension blocks are not referenceable entities.