Is the current abstract static members proposal a good design?

[acaly]

There has been discussed under the original proposal for static abstract members #4436, but I feel it's probably better to start a new discussion specifically on its impact on the language and whether it would be good for C#.

Unexpected behaviors with static virtual members

The problem is mainly from the assumption that everything "implementing" the interface must have all its static abstract members available. However, this assumption is too breaking, because it is not compatible with many existing concepts in C# (and of many similar OOP programming languages). Specifically:

1. It breaks the symmetry among interfaces (with and without static abstract members).

Interfaces with at least one static abstract members will become different. When an interface does not contain such members, it is not affected by this proposal and behaves as expected, but once it contains one, the following bullet points illustrate the strange behaviors it will have.

2. Abstract class is no longer allowed to leave members as abstract.

This is allowed:

interface I { abstract void M(); }
abstract class C : I {}

but this is not allowed:

interface I { static abstract void M(); }
abstract class C : I {}

This is allowed:

interface I { abstract void M(); }
abstract class C : I { public abstract void M(); }

but this is not allowed:

interface I { static abstract void M(); }
abstract class C : I { public static abstract void M(); }

It also breaks the symmetry between static and non-static members.

3. It breaks the assumption that T is allowed at T2 in M<T2> where T2 : T.

This is allowed:

interface I {}
class C<T> where T : I {}
C<I> c;

This is not allowed:

interface I { static abstract void M(); }
class C<T> where T : I {}
C<I> c;

This is quite annoying as we usually think the where T : I means "where T is an I". But here C# tells us that I is not an I. This is a violation of reflexive property of equality. Generics should be orthogonal to interface, and it does not make sense for generics to be affected by a new feature added for interface.

4. It allows variables of unconstructible type.

This is similar to an example I gave in the thread of the original proposal.

public class C1<T1, T2> where T1 : T2
{
    public static C1<T2, T2> X;
}

public interface I2
{
    static abstract void M();
}

public sealed class C2 : I2
{
    private static C1<C2, I2> X;
    public static void M() {}
}

public sealed class C3 : C1<C2, I2>
{
    public static void M()
    {
        var x1 = X; //ok
        C1<I2, I2> x2 = X; //error
        M1(X); //ok
        M2(X); //error
    }
    public static void M1(object v)
    {
    }
    public static void M2<T>(T v)
    {
    }
}

Here in C3.M(), we can access the field X from base class, but we cannot use the type of this field anywhere.

Other reasons

1. Irreversible change.

The above assumption that all static abstract members from I will have an implementation in T given where T : I will be an irreversible change. Once we allow codes with this assumption to compile, reversing it (e.g., by adding a concrete constraint) will be a breaking change. C# has been careful in not having much breaking changes, so impact of this feature seems unlikely to be solvable ever in the future.

2. Existing difficulties to extend.

There are problems related to default implementation and abstract members in classes, as mentioned in the original proposal. It is unclear how they will be solved, and even whether they can ever be solved. It seems impossible to me that the default implementation will ever be possible on static abstract members under the current design.

3. Covered by Shape.

Discussion on this feature seems to start in Feb this year, with less than half-year time to design and implement. There are great proposals here in this repo like shape that has been designed for many years, and it can fully cover this proposal without having these problems. Yes it is much more difficult and cannot be added to the language soon, but we have been waiting for many years, I think it is OK for us to wait for a few more.

There are also many other great proposals in this repo that have been closed simply because they are covered by shape. It is unfair that discussions on those features are closed so quickly without much thinking, while this one, also covered by shape and with all the problems mentioned above, to be implemented first.

[HaloFour]

This is allowed:

interface I { abstract void M(); }
abstract class C : I {}

That has never been allowed in C#: error CS0535: 'C' does not implement interface member 'I.M()'

Discussion on this feature seems to start in Feb this year, with less than half-year time to design and implement. There are great proposals here in this repo like shape that has been designed for many years, and it can fully cover this proposal without having these problems.

This feature proposal came specifically from the discussions around shapes and it was identified as one of the runtime changes necessary to make shapes possible.

[HaloFour]

I don't see any advantage of using interfaces as constraints over shapes.

The advantage is in not having to invent a completely new concept within the language to describe something that has a 90% overlap with interfaces.

[acaly]

The advantage is in not having to invent a completely new concept within the language to describe something that has a 90% overlap with interfaces.

I see. I thought about this again and I am now convinced it's better than having a completely new concept. The only thing I cannot agree with is that we should not cover that 10% gap with interface. It really breaks people's knowledge on interface and virtual methods today. I hope we will not be writing interface keyword when using other, more advanced shape features, if those are to be implemented.

[HaloFour]

I hope we will not be writing interface keyword when using other, more advanced shape features, if those are to be implemented.

http://gafter.blogspot.com/2017/06/making-new-language-features-stand-out.html

[acaly]

I hope we will not be writing interface keyword when using other, more advanced shape features, if those are to be implemented.

When I said keywords, I was thinking about the record, which is clear. It uses a different keyword record (or record class) to generate a class under the hood (one can make a similar one by manually writing those generated code). In this way, it keeps everything related to class intact while introducing new features. I am not proposing, I am just explaining, but declaring more advanced shape features with shape interface I or similar seems better to me than interface I, because it explicitly reminds people that it's slightly different than traditional interfaces (for example, maybe it should not be used as generic arguments at all, which excludes the TypeLoadException problem).

[acaly]

I realized the problem of where T1 : T2 actually arises from type theory. I only have a little knowledge related to type theory so please correct me if I am wrong. Today where T1 : T2 is actually a first-order logic. If we allow interfaces to be predicates of types, while at the same time to be matched by where clause, the where clause must be at least second-order logic.

I remember reading some related issues before in this repo but I cannot find them. What is the thinking of language design team on this question now? Will we disallow interfaces to be matched by where clause, or add second-order logic in where clause?

[acaly]

An example showing a valid C# to generate TypeLoadException when executing:

public interface I
{
    static abstract void M();
}

public class C : I
{
    public static void M()
    {
    }
}

//C1<I> is invalid, because it calls I.M(), which does not exist. However, we can create a C1<I> as below.
public class C1<T> where T : I
{
    public void E()
    {
        T.M();
    }
}

//Two storage classes that stores the invalid interface implementation.

public class GenericStorage<T1>
{
    public static IExecuteInvalid E;
    
    public interface IExecuteInvalid
    {
        void Execute<T2>() where T2 : T1;
    }
}

public class NongenericStorage : GenericStorage<I>
{
    private class CExecuteInvalid : IExecuteInvalid
    {
        public void Execute<T2>() where T2 : I
        {
            var x = new C1<T2>();
            x.E();
        }
    }
    
    public static void Set()
    {
        E = new CExecuteInvalid();
    }
}

//Helper class to access GenericStorage<I>.E.Execute<I>.
public sealed class C3<T>
{
    public static void M()
    {
        GenericStorage<T>.E.Execute<T>();
    }
}

public class Program
{
    static void Main()
    {
        //Create an implementation that bypasses generic check.
        NongenericStorage.Set();
        
        //Call GenericStorage<I>.E.Execute<I>, which calls C1<I>.E().
        C3<I>.M();
    }
}

[HaloFour]

Sounds like a situation that the compiler should try to identify and raise a compiler error.

[acaly]

I have mentioned this in the other thread: #4436 (comment)

I don't think it's possible unless we forbid C<T2, T2> for C<T1, T2> where T1 : T2 in general case, but that is also a breaking change.

IMHO, adding the concrete constraint is the best solution.

[Joe4evr]

IMHO, adding the concrete constraint is the best solution.

In the mean time, I have [NonAbstractOnly] in my Constraints analyzers. 🙃

[333fred]

There's a lot of interesting feedback here that we'll be sure to look at. Remember, though, that abstract statics in interfaces is in preview in .NET 6. We absolutely can make breaking changes in the design and implementation of the feature before it ships in a supported fashion. So there's no dire "stop the presses you're making a terrible mistake" problem here.