# 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.


