Proposal: Allow use of static methods/properties in Interfaces

[CharlesTaylor7]

Scenario: I have an INumeric interface. I want implementations of INumeric to have a static Parse method and a static Zero property.
What I would like:

public interface INumeric<T>
{
    T Add(T number);
    static T Zero { get; }
    static T Parse(string text);
}

public class Complex : INumeric<Complex>
{
    public double Real { get; }
    public double Imaginary { get; }

    public Complex(double real, double imaginary)
    {
        Real = real;
        Imaginary = imaginary;
    }

    public Complex Add(Complex number) => throw new NotImplementedException();
    public static Complex Zero => new Complex(0, 0);
    public static Complex Parse(string text) => throw new NotImplementedException();
}

public static class GenericExample
{
    public static T Sum<T>(this IEnumerable<T> enumerable) where T : INumeric<T>
    {
        return enumerable.Aggregate(T.Zero, (total, next) => total.Add(next));
    }
}

The proposed change is simply:

• I can verify that an implementing class has a static method/property with the appropriate signature
• I can refer to static methods/properties from a generic type argument (e.g. T.Zero)
• For consistency sake, we would allow abstract static declarations with similar behavior

As things sit, I have to use hacky workarounds to get generic code working, or implement what should be static methods as instance methods.

[jnm2]

[Proposal] Static abstract members: #809

Duplicate of dotnet/roslyn#2204.

[CharlesTaylor7]

Glad to see I'm not the only who wants this. :)

[HaloFour]

Check out #164, it's aim is to solve a lot of these problems through some compiler sorcery.

Actually adding required static members to interfaces would be impossible. Virtual dispatch requires a virtual table which belongs to a specific instance.

[jnm2]

Oh, only non-virtual static methods will be available for interfaces in #52. My mistake.

@HaloFour has a good point.

[CharlesTaylor7]

@HaloFour What do you mean each instance holds a v-table? An object would need know only about its particular implementation right? I thought a v-table was a dictionary that lived in a class definition.

[HaloFour]

@CharlesTaylor7

Yes, there is only one vtable per class definition, but each instance has its own pointer to that specific vtable for its type. Virtual dispatch has to dereference that pointer to get to the vtable to know which method to call. Without an instance there wouldn't be a pointer to a vtable and the CLR wouldn't know where to dispatch that call.