Allow interfaces with static abstract methods as type arguments when usage is safe

[DPDmancul]

Currently, interfaces with static abstract members are treated as completely prohibited in type argument positions. The compiler disallows using them as type parameters, even in contexts where it would be perfectly safe.

The reason for the prohibition is clear: if a type parameter is constrained to such an interface, the caller could invoke the static abstract member, which is undefined (just like instantiating an abstract class and calling an abstract method).

But consider the following example

public interface IMyInterface
{
    public static abstract void MyMethod();
}

public class Program
{
    public static void Problematic<T>() where T : IMyInterface =>
        T.MyMethod();

     public static void Safe<T>() =>
        Console.WriteLine("Cannot call MyMethod from here");

    public static void Main()
    {
        Problematic<IMyInterface>();   // Should be disallowed
        Safe<IMyInterface>();          // Should be allowed
    }
}

• Problematic<IMyInterface>() should remain invalid, because it can invoke an unimplemented static abstract method;
• but Safe<IMyInterface>() should be allowed, since no static abstract member access is possible.

Indeed we can declare arrays with these interfaces as element types (i.e IMyInterface[]). For the same reason we should (but currently cannot) be allowed to declare lists, enumerables,... and also to call extension methods on them. Currently you can declare an array of interfaces with static abstract methods, but you cannot, for example, use LINQ on them, since even if the type parameter of the extension methods in inferred, it still cannot be set as such interfaces. But there is no reason for this: in such cases where there is no harm (since you cannot call the abstract methods, not knowing them), it should'nt be disallowed to use such interfaces as type parameters.

Proposal

Relax the restriction so that:

• Unsafe cases, where a type parameter is constrained to the interface, allowing static abstract calls, remain disallowed;
• Safe cases, where static abstract members cannot be called, are permitted.

[CyrusNajmabadi]

but Safe() should be allowed, since no static abstract member access is possible.

How does the compiler know this? In metadata the signatures are the same.

[colejohnson66]

Problematic has a generic constraint that Safe doesn't

[333fred]

See #5955.

[DPDmancul]

I understand. So what we are missing is a "concrete implementation" constraint, for example:

abstract class C<T>
{
    public abstract void M<U>() where U : T;
    public void M0() { M<T>(); }
}
interface I
{
    static abstract string P { get; }
}
class D : C<I>
{
    public override void M<U>() => Console.WriteLine(U.P); // error: cannot call U.P since we are not sure U is concrete
}

abstract class C<T>
{
    public abstract void M<U>() where U : concrete, T;
    public void M0() { M<T>(); }
}
interface I
{
    static abstract string P { get; }
}
class D : C<I> // error: I is not concrete
{
    public override void M<U>() => Console.WriteLine(U.P);
}

[333fred]

Yes, that could be one way of solving this issue.

[jnm2]

disallows abstract ducks