LDM Notes for October 9th, 2024

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-10-09.md

Agenda

• Extensions

[yaakov-h]

Is there an option to keep both versions of extensions around in an non-binary-compatible and non-interoperable manner, but migrate codebases forwards with a attributes and potentially code fixers to update code to new extensions plus source generators to generate the old-style extension methods?

e.g. something like:

[ExtensionMethodsTypeName("EExtensions")]
extension E for T
{
    public void Foo() => throw null;

    [GenerateExtensionMethod]
    public void Bar() => throw null;
}

// Generates something like:
static class EExtensions
{
    [OverloadResolutionPriority(-1)]
    [EditorBrowsable(Never)]
    public static void Bar(this T self) => self.Bar();
}

[MgSam]

I mostly like the new proposal for the per-member syntax, but I'm not convinced about the need for the new extension keyword in this universe. It seems like it brings two benefits:

• Possibility for saving keystrokes by having the for clause apply to all members
• Disambiguation syntax by using casting

In my opinion, the cons outweigh the pros here. It's yet another new "type" keyword, will cause confusion about why/how its different from static class, and worse yet- is not actually a type! Extension methods are write-once, rarely touched pieces of code- I think a little extra verbosity in having to repeat for is fine.

The disambiguation syntax I think needs to go back to the drawing board. It is super confusing to have an apparent type-cast for something that is not a type. "Extension properties" et al, will really just be static methods with syntax sugar- so why not just generate them as human-callable names and let them be called as static methods if a user really needs to disambiguate? Eg, var myCount = ListExtensions.get_Count(list);

My vote is to stick with the existing static class model for writing extensions and the only new addition is the for syntax.