Should adding a static (non-virtual, non-abstract) member to an interface be considered breaking?

[jskeet]

Type of issue

Other (describe below)

Description

Currently, adding a member to an interface is disallowed.

I would like to propose that adding a static non-abstract, non-virtual member to an interface (for runtimes that handle that) should be allowed.

For example, suppose the .NET team were to add a static property to IDisposable. Note that I've added the access modifiers just for clarity, and NoOpDisposable would be better as a singleton. In reality this would presumably have to only be exposed on particular runtimes as well - but let's consider a ".NET 8 only" world for now.

public interface IDisposable
{
    public void Dispose();

    public static IDisposable NoOp => new NoOpDisposable();

    private class NoOpDisposable : IDisposable
    {
        public void Dispose() {}
    }
}

You could then write:

IDisposable x = IDisposiable.NoOp;

I think that shouldn't count as a breaking change. (Motivation: I have a PR for Noda Time which in its current form does this for IClock: https://github.com/nodatime/nodatime/pull/1816 - the ApiCompat tooling treats this as a breaking change.)

Is there a scenario I'm missing where this would be a breaking change (binary or source)?

Page URL

https://learn.microsoft.com/en-us/dotnet/core/compatibility/library-change-rules#members

Content source URL

https://github.com/dotnet/docs/blob/main/docs/core/compatibility/library-change-rules.md

Document Version Independent Id

79a4adc9-b2c9-68b7-669e-2bd8d2d44faf

Article author

@gewarren

Metadata

• ID: c4b482b0-6dd1-42de-5389-5b0b47823402
• Service: dotnet-fundamentals

Related Issues