[API Proposal]: Consistent interface members

[Shadowblitz16]

Background and motivation

I realized that static interface have different syntax then instance members

API Proposal

namespace System.Collections.Generic;

public interface IStaticDefault
{
    static void A1();
    static void A2()
    {
        
    }
}
public interface IStaticAbstract
{
    static abstract void A1();
    static abstract void A2()
    {
        
    }
}
public interface IStaticAccess
{
    public static void A1();
    public static void A2()
    {
        
    }
    protected static void B1();
    protected static void B2()
    {
        
    }
    private static void C1();
    private static void C2()
    {
        
    }
}
public interface IStaticBoth
{
    public abstract static void A1();
    public abstract static void A2()
    {
        
    }
    protected abstract static void B1();
    protected abstract static void B2()
    {
        
    }
    private abstract static void C1();
    private abstract static void C2()
    {
        
    }
}

public interface IInstanceDefault
{
    void A1();
    void A2()
    {
        
    }
}
public interface IInstanceAbstract
{
    abstract void A1();
    abstract void A2()
    {
        
    }
}
public interface IInstanceAccess
{
    public void A1();
    public void A2()
    {
        
    }
    protected void B1();
    protected void B2()
    {
        
    }
    private void C1();
    private void C2()
    {
        
    }
}
public interface IInstanceBoth
{
    public abstract void A1();
    public abstract void A2()
    {
        
    }
    protected abstract void B1();
    protected abstract void B2()
    {
        
    }
    private abstract void C1();
    private abstract void C2()
    {
        
    }
}

API Usage

No API usage its makes interfaces more consistent and gives more power to the coder to decide what coding style to use

Alternative Designs

None

Risks

Shouldn't be any

[HaloFour]

The changes to permit explicit access modifiers and abstract modifiers on instance members has already been merged and the following is legal:

public interface I {
    public abstract void M1();
    protected abstract void M2();
    
    public static abstract void SM1();
    protected static abstract void SM2();
}

You can declare private members, but they cannot be abstract/virtual since that would prevent them from being implemented or invoked from outside of the interface. You can use them for helper methods.

[CyrusNajmabadi]

I'm not sure what actual language change is being asked for here. Can you clarify what you would like to be different/allowed/disallowed?

[HaloFour]

Right now static interface members can't just be...

static void A();

This is because static non-virtual members are already supported by C#, there needed to be a way to differentiate them.

Also I am unsure is the abstract keyword is supported for instance members, aka..

abstract void B();

Yes, the C# compiler will allow you to add abstract and/or public modifiers to instance members.

public interface I {
    public abstract void B();
    // is the same as
    void B();
}

The point of the suggestion is to allow any of these keywords to be used for both static and instance, default implementations and interface implementations

This will be the case with C# 11 as it stands, with the exception that private members cannot be abstract/virtual as they cannot be overridden. But you may declare non-virtual private static/instance members for use as helper methods within the interface.

[Shadowblitz16]

Right now static interface members can't just be...

static void A();

This is because static non-virtual members are already supported by C#, there needed to be a way to differentiate them.

Also I am unsure is the abstract keyword is supported for instance members, aka..

abstract void B();

Can you explain this? interfaces are just a contract.
the way you differentiate them is by the static keyword.

If you have a static keyword in a interface it just means it forces it to be static in the class or struct implementation

[HaloFour]

If you have a static keyword in a interface it just means it forces it to be static in the class or struct implementation

C# has supported non-virtual static members in interfaces since 7.0:

using System;

interface I {
    public static void M() {
        Console.WriteLine("Hello");
    }
}

static class Program {
    static void Main() {
        I.M();
    }
}

This is not a virtual member and there is no requirement that an implementing class implement that static method. Even if it did, it would be unrelated to the method on the interface and cannot be called virtually through the interface member. This is why abstract is required on these new virtual static members, to differentiate them from non-virtual static members.

[Shadowblitz16]

If you have a static keyword in a interface it just means it forces it to be static in the class or struct implementation

C# has supported non-virtual static members in interfaces since 7.0:

using System;

interface I {
    public static void M() {
        Console.WriteLine("Hello");
    }
}

static class Program {
    static void Main() {
        I.M();
    }
}

This is not a virtual member and there is no requirement that an implementing class implement that static method. Even if it did, it would be unrelated to the method on the interface and cannot be called virtually through the interface member. This is why abstract is required on these new virtual static members, to differentiate them from non-virtual static members.

I don't understand why this which is currently supported

interface I
{
    public static void M();
}

can't be inferred by this which is currently not supported

interface I 
{
    static void M();
}

default implementations are just that nothing more.
The shouldn't act any different then default implementations of instance members in interfaces

class C : I
{
    //  public static abstract void M(); // ok
    //  private static abstract void M(); // not ok
    //  public abstract void M(); // not ok
    //  public static void M()  // ok
    //  {
    //  }
}

[HaloFour]

Because existing static members on interfaces are not virtual, to reinterpret them as virtual would change the meaning of existing code which would be confusing and could potentially lead to breaking changes.