LDM Notes for November 13th, 2024

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-11-13.md

Agenda

• Extensions

[qrli]

    extension<T> (T) where T : class?
    {
        [param:NotNull] public void ThrowIfNull() => ArgumentNullException.ThrowIfNull(this);
    }

The [param:NotNull] does not feel like modifying this at all. I'd expect something like [this:NotNull], which would be obvious even to people who read such syntax for the 1st time.

[qrli]

Mixing underlying types within an extension declaration

How is

public static class CSharpExtensions
{
    extension
    {
        public bool (SyntaxToken).IsKind(SyntaxKind kind) => ...;
        public bool (SyntaxTrivia).IsKind(SyntaxKind kind) => ...;
        [param: NotNullWhen(true)]
        public bool (SyntaxNode?).IsKind(SyntaxKind kind) => ...;
        public bool (SyntaxNodeOrToken).IsKind(SyntaxKind kind) => ...;
        public bool (SyntaxNode).ContainsDirective(SyntaxKind kind) => ...;
    }
}

any better than the old

public static class CSharpExtensions
{
    public static bool IsKind(this SyntaxToken token, SyntaxKind kind) => ...;
    public static bool IsKind(this SyntaxTrivia trivia, SyntaxKind kind) => ...;
    public static bool IsKind([NotNullWhen(true)] this SyntaxNode? node, SyntaxKind kind) => ...;
    public static bool IsKind(this SyntaxNodeOrToken nodeOrToken, SyntaxKind kind) => ...;
    public static bool ContainsDirective(this SyntaxNode node, SyntaxKind kind) => ...;
}

if the old extension method syntax will still be around?

[alrz]

any better than the old

It can be consistently used for all instance and static extension member forms. While the old one is only for instance extension _method_s.

I believe the question is not about what it enables, rather, that it looks even more verbose than using this args and tbh a little bit forgiving on aesthetics.

I think I'd really like to read arguments against type based approach since that's where this started with interface extentions in mind, but now it feels like it has been reduced to a sugar that almost doesn't read like C#, IMO.

[CyrusNajmabadi]

rather, that it looks even more verbose than using this args

That may be what is required to support all the different member forms.

That said, it will commonly be less verbose when you have many extension members as you will not have to repeat the receiver N times (one per member).

So, we believe it is a net win. It enables many new extension forms, and reduces overhead per member. Even at a couple of members you're already ahead, and it improves the more you have.

I think I'd really like to read arguments against type based approach

We ended up finding examples of virtually every type of extension out there in real packages. That meant the type approach ended up needing significant extensions itself to be a suitable replacement for existing extension methods. And those extensions were getting more and more ungainly.

We had proposals on both. One approach felt like it solved all the use cases in a much more cohesive fashion. The other nailed a smaller set of cases, but felt really bad for a bunch of other important ones. We decided based on that.

[alrz]

We decided based on that.

I understand there's tradeoffs to account for with either option, but I think this could be a style preference at the very least instead of only focusing on the migration story.

I'd imagine support for three forms (type, block, member) wouldn't be too much syntax since it's just a kind of modifier? I feel comfortable suggesting that because it's been considered to allow single-member extension as well as extension blocks. The former can address the indentation problem but there's no savings on the character count.

[HaloFour]

I'd imagine support for three forms (type, block, member) wouldn't be too much syntax since it's just a kind of modifier?

I believe that was explicitly expressed in the meeting notes for the "unified" extensions proposal:, under "shorter forms":
https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-11-20.md

The syntax included is just illustrative of the concept.

[alrz]

The syntax included is just illustrative of the concept.

The most interesting part in that is the instance members in a static class.

If we can get passed that, this would be the two forms next to each other:

static class E {
    extension(IEnumerable) {
        // instance members
    }
    extension<T>(IEnumerable<T>) {
        // instance members
    }
    // static members
}

extension(IEnumerable)
static partial class E {
  // instance members
}

extension<T>(IEnumerable<T>)
static partial class E {
  // instance members
}

static partial class E {
  // static members
}

With that, single-member form would actually save more when there's more regular members than extensions.

static partial class E {
   extension(int) 
   private bool IsZero => ..

   extension(string) 
   private bool IsEmpty => ..

  // static members
}

I assume explicit extension members cannot appear in another extension class though.

[jnm2]

I didn't say "entomology" to start with 😂

[markm77]

Just added a comment on extensions proposal here.

[DavidArno]

I think there are some seriously flawed assumptions within this proposal:

It is this author’s belief that programmers will resent being forced to separate extension declarations by underlying type...

As far as this programmer is concerned, the author is deeply mistaken. I always organise extension by the underlying type. Not doing so is messy and complicates the code in my view. Without clear empirical evidence, such guesses/beliefs risk delivering the wrong solution for the majority of devs.

Also, I do not understand why these extensions are being embedded in a static class. For me, I'd far prefer the example shown with the code:

public static class CSharpExtensions
{
    extension(SyntaxToken)
    {
        public bool IsKind(SyntaxKind kind) => ...;

were expressed as:

public extension(SyntaxToken)
{
    public bool IsKind(SyntaxKind kind) => ...;
}
    
public extension(SyntaxTrivia)
{
    public bool IsKind(SyntaxKind kind) => ...;
}

public extension(SyntaxNode?)
{
    [param: NotNullWhen(true)]
    public bool IsKind(SyntaxKind kind) => ...;
}

public extension(SyntaxNodeOrToken)
{
    public bool IsKind(SyntaxKind kind) => ...;
}

public extension(SyntaxNode)
{
    public bool ContainsDirective(SyntaxKind kind) => ...;
}

with the option to fall back to using this if I really need to:

public extension
{
    public bool IsKind(this SyntaxToken token, SyntaxKind kind) => ...;
    public bool IsKind(this SyntaxTrivia trivia, SyntaxKind kind) => ...;
    public bool IsKind([NotNullWhen(true)] this SyntaxNode? node, SyntaxKind kind) => ...;
    public bool IsKind(this SyntaxNodeOrToken nodeOrToken, SyntaxKind kind) => ...;
    public bool ContainsDirective(this SyntaxNode node, SyntaxKind kind) => ...;
}

The removal of all those noisy static keywords being motivation to rewrite existing extension methods into this form.

[CyrusNajmabadi]

But with new syntax, it's not apparent whatsoever. Therefore, the language needs to guarantee that

You have it incorrect. By doing it in the language itself, we can guarantee things. Having stubs, with different semantics on each side of the stub has no guarantees around compat, and you cannot 'visually' confirm anything.

[CyrusNajmabadi]

This is easily achieved in the syntactically "typed" form as well.

Can you give an example of this?

[CyrusNajmabadi]

Needless to say, what was originally envisioned as a straightforward,

There was nothing straightforward about the original release. Both on the design and implementation side we ran into enormous problems. That's why we were trying to prototype it out. It was to see how viable it was. We didn't guess at the unviability of it. It was proven out by several compiler devs going down that path and determining just how problematic things were. This was also confirmed by runtime team which came back with several hard blockers on the prior design that made is super undesirable to go that route.

[CyrusNajmabadi]

Ditto.

What is your approach for disambiguation given David's preferred syntax?

[CyrusNajmabadi]

be "transferable" to the new syntax and maintain binary compatibility.

This is not fully accurate. Binary, source, and behavioral compat are all important to portions of the C# ecosystem. We cannot blithely handwave that away just because we have small groups that are ok with breakage in any of these areas.

[MgSam]

Maybe I missed it, but in the new proposal how to do you statically call the new extension methods? Given they will be generated inside some form of unspeakable class. Being able to do call them statically is critical for disambiguation scenarios, no?

[CyrusNajmabadi]

It's an open question. But one we feel we have many possible solutions for. For example, we could raise existing syntax like so: ((MyEtensions)val).IsEmpty. Or we could make new syntax. We don't feel like this is a critical thing to solve currently.

[HaloFour]

It would be nice if there was a relatively simple way for downlevel (or non C#) languages to call extensions. Keeping it simple also means that C# doesn't need to invent a syntax for that purpose. IMO, that should be part of the conversation of lowering the extensions, especially since that represents a public API.