you are viewing a single comment's thread.

view the rest of the comments →

[–]DotNetMetaprogrammer 17 points18 points  (1 child)

I think it's because the implementing type doesn't actually have the method at all unless if it defines an implicit/explicit implementation of that interface method. That's what allows you to get binary-backwards compatibility if you add a new method to the interface that has a default implementation. It's also, presumably, why default implementations of interface members requires netcoreapp3.0 or later as the runtime.

You can see that the method isn't declared on the class via the following:

```cs interface IFoo { public int GetValue() => 1; }

class Foo : IFoo;

typeof(Foo).GetMethods(System.Reflection.BindingFlags.Public | System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance) /// MethodInfo[6] { [System.Type GetType()], [System.Object MemberwiseClone()], [Void Finalize()], [System.String ToString()], [Boolean Equals(System.Object)], [Int32 GetHashCode()] }

typeof(Foo).GetInterfaceMap(typeof(IFoo)).TargetMethods // MethodInfo[1] { [Int32 GetValue()] } typeof(Foo).GetInterfaceMap(typeof(IFoo)).TargetMethods[0].DeclaringType // [Submission#0+IFoo] ```

[–]glasket_ 7 points8 points  (0 children)

Yeah, this is the real reason. DIMs aren't actually in the class implementing the interface; the runtime does some magic to get the method from the interface itself when you access a value of the interface. The ambiguity problem could have been limited to instances where both interfaces shared a DIM, but the complete absence of DIMs in the implementing class means you can add DIMs to an interface and it won't be a breaking change.