The proposed Default Interface Methods feature would allow a limited form of multiple inheritance in C#, F#, and other .NET languages. Inspired by Java’s default methods, library authors would be allowed to add new methods to a published interface without breaking backwards compatibility by also including a default implementation.
This is a hotly contested feature with strong opinions on both sides of the debate. And in that regard, nothing has changed. What’s new is the possibility that this would be a .NET Core only feature.
When discussing the proposal for default interface methods in F#, Phillip Carter of Microsoft wrote,
Just to call this out, default interface methods do give us a .NET runtime-supported way to support #243 (to some degree). However, this change would only be available in .NET Core, since it is highly unlikely that the desktop CLR would be modified to support the underlying runtime feature. So just like C#, F# would have a feature that only works if you're using CoreCLR.
[…]
Default interface methods require a runtime change. This means that there is also a check for seeing if the feature is supported by a given runtime: https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md#clr-support-api
No shipped .NET Framework version supports this today, and it's highly unlikely that they ever will due to the risk of breaking existing apps that are so widespread. .NET Core will eventually have this in its runtime, but it's not completely resolved if it will also be in some future .NET Framework, mono, or UWP runtime. And as @jnm2 mentioned, unless every runtime that supports a .NET Standard also has this feature, then you wouldn't be able to use them in .NET Standard. It is not in the upcoming .NET Standard 2.1 plan either.
The question in my mind, from a long-term planning perspective, is what we do beyond simply ensuring that we don't blow up in the face of such a construct. Is the feature a copy of C#? Probably not. A fully-fledged traits/typeclasses system? That would need a proper design that would take time. How would it be rationalized with existing things like SRTP? How to think about interfaces today vs. interfaces tomorrow vs. functions as interfaces vs. normal generics vs. SRTP vs. {insert thing here}? But at least in my mind, the mechanism for implementing something is coming, so it would be good to think about what that something is at a high level, what sort of behaviors it could have, and how to rationalize it with existing features in this space.
In the C# proposal thread, Joseph Musser responded with,
As a library author, this means DIM will be of no use over the situation today in evolving APIs if one of the library's targets is either .NET Framework or a version of .NET Standard which could run on .NET Framework. Adding an interface method will still be a breaking change.
To which Thomas Levesque adds “And since libraries are the single most important use case for this feature, it would make the whole feature mostly useless...”
