- Nothing particularly funny was said today, sorry.
Champion issue: #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.
Champion issue: #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.
Needs work. If we find time to look at alternatives, we may bring them back in the future.