C# Language Design Meeting for November 13th, 2024

Agenda

• Extensions

Quote(s) of the Day

• "These were my opinions, or at least they were a week ago"
• "What's the entymology of rathole?" "It's etymology" "Oh right, entymology is the study of living trees" "You just caused my brain to segfault"

Discussion

Extensions

Champion issue: https://github.com/dotnet/csharplang/issues/5497
Documents:

• https://github.com/dotnet/csharplang/blob/e84c2c9711c269243bb2084700512e3f002fec8b/meetings/working-groups/extensions/anonymous-extension-declarations.md
• https://github.com/dotnet/csharplang/blob/e84c2c9711c269243bb2084700512e3f002fec8b/meetings/working-groups/extensions/extending-extensions-a-guide-to-relaxation.md

We once again return to extensions, today with a compromise proposal to rule them all: a grouping approach that allows many of the advantages of the type-based approach (lack of repeating types, appears closer to a regular member definition) while also giving us the flexibility of the member-based approach, where a single Extensions type can contain all of a user's extensions. After going through the proposal, we were overall very positive on the approach, and think we have something specific that we can start to solve specific problems in and flesh out more. We noted a few things that need to be thought about more:

• There's a bit of split-brain logic going on with the receiver parameter in the proposal. It's referred to as this in member bodies, but the attribute syntax uses param. It's also referable to with parameter modifiers in the extension block, which looks like a parameter declaration. Which is it; this, or a parameter? While there's definitely some amount of hybridization going on here, we think we want to lean towards the param side, rather than the this side, because parameter names an provide valuable context. For example, source and destination are likely clearer names for a mapping method than this and destination.
• Along similar lines, how is the receiver documented in XMLDoc?
• Not an issue, but we pointed out that this proposal does not permit new forms of generic specialization: it does not allow indexers to take generic type parameters, for example.

After this discussion, we were able to come to a few key decisions that will help us flesh out this proposal further.

Conclusions

• We want to be able to generate compatible extension methods with this syntax. We're not committing to absolute 100% compatibility with existing extension methods, but we'd like to be able to express 99% of existing extension methods in the new format.
• Along similar lines, we think we should generate visible methods from extension declarations.
• Finally, we think that we should lean more towards treating the receiver as a parameter, rather than as this, for the next iteration of the proposal.