[API Proposal]: Allow abstract static members on classes, not only interfaces.

[Luiz-Ossinho]

Background and motivation

I was really excited for the feature of statically accessible abstract members that was announced in .NET 7.0 (documented more commonly as Generic Math) . But once i started testing, i realized that only interfaces can declare abstract static members, abstract classes get a compile error instead (CS0112).
This is a request for allowing abstract static members on abstract classes and classes.
I have since implemented some sort of workaround, but its not very intuitive and likely consumes more resources than necessary.

API Proposal

public abstract class StaticMemberAbstractClass
{
    abstract static int StaticMember { get; }
}

public abstract class StaticMemberClass
{
    override abstract static int StaticMember { get; }
}

API Usage

// Implement an class
public class StaticMemberDevivedClass : StaticMemberClass 
{
    override static int StaticMemberClass.StaticMember { get; } = 1;
}

// Statically access members with generics
public static void StaticallyAccessMemberWithGenerics<T>() where T : StaticMemberClass
{
    Console.WriteLine(T.StaticMember);
}

StaticallyAccessMemberWithGenerics<StaticMemberDevivedClass>();
// Output: 1

Alternative Designs

My current workaround for this issue:

public interface IStaticSingleton<T> where T : new()
{
    abstract static T Value { get; }
}

public abstract class StaticSingleton<T> : IStaticSingleton<T> where T : IStaticSingleton<T>, new()
{
    public static T Value { get; } = new();
}

public interface IStaticMemberInterface<TStaticMemberInterface> : IStaticSingleton<TStaticMemberInterface>
    where TStaticMemberInterface : IStaticSingleton<TStaticMemberInterface>, new()
{
    // Not really static, but still statically accessible
    int StaticMember { get; }
}
public abstract class StaticMemberClass<TStaticMemberDerivedClass> : StaticSingleton<TStaticMemberDerivedClass>, IStaticMemberInterface<TStaticMemberDerivedClass>
    where TStaticMemberDerivedClass : IStaticMemberInterface<TStaticMemberDerivedClass>, new()
{
    // Not really static, but still statically accessible
    public virtual int StaticMember { get; } = 1;
}
public class StaticMemberDerivedClass : StaticMemberClass<StaticMemberDerivedClass> { }

public void StaticallyAccessAbstractMembers<TAnyDeriveClass>() where TAnyDeriveClass : IStaticMemberInterface<TAnyDeriveClass>, new()
{
    Console.WriteLine(TAnyDeriveClass.Value.StaticMember);
}
StaticallyAccessAbstractMembers<StaticMemberDerivedClass>();
// Output: 1

Risks

No response

[ghost]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[Luiz-Ossinho]

I think the label would be "area-Microsoft.CSharp", but honestly i have no ideia, neither have write-permissions.

[RonenGlants]

This feature request is also related to an "issue" with the new abstract static member feature.
When an abstract class implements an interface with abstract static members, it is forced to define these members, and currently (as far as I can see) it is not possible to delegate the implementation responsibility to the non-abstract class.
This behavior is non-consistent with how we can currently avoid the definition in an abstract class.

For example, I can do this:

    public interface ITest
    {
        public string Name { get; }
    }

    public abstract class AbstractTest : ITest
    {
        public abstract string Name { get; }
    }

But I can not do something like this:

    public interface ITest
    {
        public abstract static string Name { get; }
    }

    public abstract class AbstractTest : ITest
    {
        public abstract static string Name { get; } // CS0112 error
    }

I think it makes sense to allow abstract classes to delegate the implementation of abstract static members.

[svick]

The problem here is that a static member doesn't need an instance, so it is possible to use an abstract static member directly on an abstract class.

For example, like this:

using System;

PrintName<AbstractTest>(); // prints "Abstract"
PrintName<ConcreteTest>(); // prints "Concrete"

void PrintName<T>() where T : ITest
{
    Console.WriteLine(T.Name);
}

public interface ITest
{
    public abstract static string Name { get; }
}

public abstract class AbstractTest : ITest
{
    public static string Name => "Abstract";
}

public class ConcreteTest : AbstractTest, ITest
{
    public static new string Name => "Concrete";
}

[RonenGlants]

The issue here is that as a developer I want to force in compile time all different ConcreteTests that inherit from AbstractTest to implement Name.
By implementing a default value I am open to errors if someone will forget to override it.
Even if I will throw as a default implementation, it is still not good enough because it will be discovered at run time.

[svick]

You could create an analyzer that reports an error when a ConcreteTest does not implement a Name. I can't think of any better option.

[jkindwall]

What if abstract static members in classes were required to provide a default implementation just in case someone calls it on the abstract class directly? Something like this:

using System;

PrintName<AbstractTest>(); // prints "Abstract"
PrintName<ConcreteTest>(); // prints "Concrete"

void PrintName<T>() where T : ITest
{
    Console.WriteLine(T.Name);
}

public interface ITest
{
    public abstract static string Name { get; }
}

public abstract class AbstractTest : ITest
{
    public abstract static string Name => "Abstract";
}

public class ConcreteTest : AbstractTest, ITest
{
    public static string Name => "Concrete";
}

Its nearly identical to the previous example except for the following:

1. The "abstract" keyword is added to the member in the AbstractTest class, thus indicating that even though there is a default implementation, any concrete class deriving from this class is contractually obligated to provide its own implementation.
2. The "new" keyword is not needed in the concrete implementation, because it is assumed that the abstract member implementation is meant to be replaced.

[jkindwall]

Or... Here's another option:

Currently if you try to do this in either of the above examples:

PrintName<ITest>()

you will get the following compile-time error:

error CS8920: The interface 'ITest' cannot be used as type argument. Static member 'ITest.Name' does not have a most specific implementation in the interface.

Likewise, if you have another interface that derives from ITest and you try to use it as a type parameter to PrintName<>(), you'll get the same error.

Why can't the same apply to an abstract class that doesn't provide the implementation? So in all you would have a situation like this:

using System;

PrintName<ITest>(); // CS8920 error
PrintName<ISubTest>(); // CS8920 error
PrintName<AbstractTest1>(); // prints "Abstract"
PrintName<AbstractTest2>(); // CS8920 error
PrintName<ConcreteTest>(); // prints "Concrete"

void PrintName<T>() where T : ITest
{
    Console.WriteLine(T.Name);
}

public interface ITest
{
    abstract static string Name { get; }
}

public interface ISubTest : ITest
{
    string SubName { get; }
}

public abstract class AbstractTest1 : ITest  // Provides implementation for static member
{
    public static string Name => "Abstract";
}

public abstract class AbstractTest2 : ITest // Does not provide implementation for static member
{
    public static abstract string Name { get; }
}

public class ConcreteTest : AbstractTest2
{
    public static string Name => "Concrete";
}

This way we get compile-time enforcement that the concrete class has the responsibility to fulfill the static member contract, and we don't have any weird runtime errors if someone tries to use the abstract class as a type argument where it is not intended, because the CS8920 error will catch it.

[0x0737]

Shouldn't this use the override keyword if the abstract method is defined in a class? It would be logical to have it along abstract and virtual just like with instance members and with the same hiding mechanism.

[Luiz-Ossinho]

Sorry, my mistake, i will edit this.

[Luiz-Ossinho]

I must havent tested it before, but @jkindwall actually works for me, as it enables "override-like" behaviour, even tough it uses the opposite keyword "new".

 public interface ITest
  {
      public abstract static string Name { get; }
  }

  public abstract class AbstractTest : ITest
  {
      public static string Name => "Abstract";
  }

  public class ConcreteTest : AbstractTest, ITest
  {
      public static new string Name => "Concrete";
  }

 void Test<TTest>() where TTest : ITest => Console.WriteLine(TTest.Name);

Test<AbstractTest>();
// Output: Abstract

Test<ConcreteTest>();
// Output: Concrete

What if abstract static members in classes were required to provide a default implementation just in case someone calls it on the abstract class directly? Something like this:

using System;

PrintName<AbstractTest>(); // prints "Abstract"
PrintName<ConcreteTest>(); // prints "Concrete"

void PrintName<T>() where T : ITest
{
    Console.WriteLine(T.Name);
}

public interface ITest
{
    public abstract static string Name { get; }
}

public abstract class AbstractTest : ITest
{
    public abstract static string Name => "Abstract";
}

public class ConcreteTest : AbstractTest, ITest
{
    public static string Name => "Concrete";
}

Its nearly identical to the previous example except for the following:

1. The "abstract" keyword is added to the member in the AbstractTest class, thus indicating that even though there is a default implementation, any concrete class deriving from this class is contractually obligated to provide its own implementation.
2. The "new" keyword is not needed in the concrete implementation, because it is assumed that the abstract member implementation is meant to be replaced.

[EtiTheSpirit]

Currently this behavior is vital for my upcoming public API, especially with respect to static override members.

One of my API's features allows binding C# classes to Java classes by name, for interoperability with legacy software. To achieve this, I have an interface IJavaClass with static abstract JavaClass Class { get; }

I recently ran into a strange behavior with the interface implementation. My class hierarchy is as follows for this scenario:

ManagedConfig : IJavaClass
└ParameterizedConfig : ManagedConfig, IJavaClass // Note the explicit implementation here. I shadow `Class` here.
 └TextureConfig : ParameterizedConfig // Note the *lack of* an explicit implementation here. I shadow `Class` here too, however!

When writing a method to access this Class member on a generic type...

public static JavaClass ByInnerName<TOuter>(string name) where TOuter : IJavaClass {
  return ByName($"{TOuter.Class.Name}${name}");
}

The call ByInnerName<TextureConfig>("Implementation") resulted in a call to ByName with the string ParameterizedConfig$Implementation, which is unexpected - I was expecting to see TextureConfig$Implementation. This was caused by the lack of an explicit implementation of IJavaClass on TextureConfig (as in, putting the interface in with the type signature), so the generic type fell back to that of ParameterizedConfig due to its explicit implementation.

This behavior is potentially an error on its own (it implies that the static Class property should be inherited (and thus able to be overridden) by the very nature of this behavior, namely in that it "fell back" to the parent class, comparable to something like callvirt get_Prop on an instance member) but, as the existence of this proposal indicates, this member is not actually able to leverage inheritance at all - not only would this feature request address what I consider to be a rather nice addition to the API, but it would also get rid of this unexpected problem.