# C# Language Design Meeting for February 24th, 2025

## Agenda

- [Extensions](#extensions)
- [Interpolated string handler method names](#interpolated-string-handler-method-names)

## Quote of the Day

- Nothing particularly funny was said today, sorry.

## Discussion

### Extensions

Champion issue: https://github.com/dotnet/csharplang/issues/8697  
Specification: https://github.com/dotnet/csharplang/blob/3ee9dcaae3800cdbbf16bc50dffc483de16576af/proposals/extensions.md  
Reviewed document: https://github.com/dotnet/csharplang/blob/3ee9dcaae3800cdbbf16bc50dffc483de16576af/meetings/working-groups/extensions/Extension-API-docs.md

Today, we took a break on extensions from talking about deep philosophical questions, to simply looking at what the docs team is proposing for how new extensions
are going to be displayed. Unfortunately, a few of the major decisions that we still need to resolve around compat will likely impact what the docs team displays;
can they just always use the new format, or will knowing whether an extension is new or old style be relevant to a user? That will hold up some of their work, but
we otherwise don't have any particular notes on the current proposal.

### Interpolated string handler method names

Champion issue: https://github.com/dotnet/csharplang/issues/9046  
Specification: https://github.com/dotnet/csharplang/blob/a970d01597886d84d7498e1b6a9d8e8e8ebf02c1/proposals/interpolated-string-handler-method-names.md

Finally, we took a look at this proposal around expanding interpolated string handler arguments to handle a logging scenario. There's consternation among the LDM
around the relative lack of purity in this approach; after all, names aren't the real thing that the type author wants, it's the log level. And it would potentially
limit reuse of handlers built with this approach, since users who want to reuse such handlers from the BCL would need to name their methods exactly as the BCL methods
are named, otherwise it wouldn't work. On the other hand, some members of the LDM are concerned about the investment here, and whether we're going to reach our old
standby of 100 points digging further into this problem. The existing workaround of copy/pasting the handler 7ish times isn't pretty, but these handlers are not a
large maintenance burden and are not touched very often after creation, and this approach _would_ provide that reusability guarantee that the BCL needs. Given the
divide on this issue, then, we'll put it into the "Needs Work" milestone, and if we have time in the future, we might consider revisiting it; at that point, we can
compare what the more complex solution would look like with the simple approach in this proposal.

#### Conclusion

Needs work. If we find time to look at alternatives, we may bring them back in the future.
