LDM Notes for October 7th, 2024

[333fred]

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

Agenda

• Extensions

[DavidArno]

One thing we clarified during discussion is that, even though we've arrived at the idea that extension types aren't actually types and can't be the type of an instance variable today, we haven't ruled out that extension types could implement interfaces in the future, allowing the user to implicitly treat the underlying type as having implemented that interface without having to do any casts.

Hmm, that sounds very much like structural typing to me. Extensions for the win!💯

[DavidArno]

Something needs to provide the vtable that allows virtual dispatch to work. That something cannot be the original type, since it didn't implement I, so it must be E.

But that appears to contradict what you said before, "allowing the user to implicitly treat the underlying type as having implemented that interface without having to do any casts". I read that as you saying that the original type can be viewed as now implementing I. E is just extending C, so if E adds nothing new, its vtable should be that of C, surely?

[333fred]

But that appears to contradict what you said before, "allowing the user to implicitly treat the underlying type as having implemented that interface without having to do any casts". I read that as you saying that the original type can be viewed as now implementing I. E is just extending C, so if E adds nothing new, its vtable should be that of C, surely?

It doesn't add nothing new. It adds an implementation of I, so its VTable cannot be empty. Even if the compiler decided to allow that case to work seamlessly from the user's perspective (appearing to need to write nothing extra), the compiler would need to emit a bridge method to implement that interface. When you convert the underlying type to that interface, some kind of witness will need to be introduced.

[DavidArno]

OK, so I could do:

sealed class Foo
{
    void Bar() => etc
}

interface IFoo
{
    void Bar();
}

extension Baz of Foo : IFoo
{
    void Bar() => Foo.Bar() // syntax not important
}

And as you say, the compiler could emit that automatically. If it did emit it automatically, then we now have Foo implementing IFoo after the event.

Make the compiler do that and we have that 💯 ...

[333fred]

Sure, if we added automatic emitting of the extension itself, we'd have structural typing. But we actively do not want that at the moment, which is why we long ago moved away from shapes.

[DavidArno]

Sure, if we added automatic emitting of the extension itself, we'd have structural typing. But we actively do not want that at the moment, which is why we long ago moved away from shapes.

Fair enough. And should people want structural typing via this method, they can always use a source generator to generate those mappings to implement the interface in a generated extension.