Virtual/Abstract Static Members in Classes

[TheBrambleShark]

In [Proposal]: Static abstract members in interfaces (#4436), it was suggested that a future feature may be adding support for static abstract members in classes:

Virtual static members in classes

Another additional feature would be to allow static members to be abstract and virtual in classes as well. This runs into similar complicating factors as the default implementations, and again seems like it can be saved for later, if and when the need and the design insights occur.

There have been a few situations I have encountered where I run into a few conditions:

1. I need common, static functionality across all concrete types in a set.
2. Other non-abstract functionality relies on that static abstract member.
3. I want to access that static abstract member from the base type.

Take the following example:

public abstract class AnimalBase
{
    // Implementing types are required to implement this member.
    public static abstract string SpeciesName { get; }

    // Abstract and virtual members are only allowed on abstract
    // classes?
    public static virtual void Pet()
        => Console.WriteLine($"You pet the {SpeciesName}");
}

public sealed class Giraffe : AnimalBase
{
    // Must implement SpeciesName.
    public static string SpeciesName => nameof(Giraffe);

    // Overriding the static default implementation.
    public static override void Pet()
        => throw new InvalidOperationException("The giraffe's head is too high to reach!");
}

This design does leave a few open questions:

1. Can we "bubble up" static interface members? That is, suppose we have the following interface:

public interface IAnimal
{
    static abstract string SpeciesName { get; }
    static abstract void Pet();
}

Should we then allow the following?

public abstract class AnimalBase : IAnimal
{
    // Bubbles up the requirement for the final animal to implement SpeciesName
    public static abstract string SpeciesName { get; }

    // Abstract class is providing a default implementation.
    public static virtual void Pet()
        => Console.WriteLine($"You pet the {SpeciesName}");

}

2. Can we allow the base keyword for static virtual members? I don't see any immediate restrictions but a static instance is not the same as a non-static instance, so there may be some interference.
3. Is the abstract keyword on the class declaration required? I think it should be a requirement to avoid situations where an class containing a static abstract member becomes the most specific member, leaving the static abstract member undefined.
4. Are there any semantics we'll need to be concerned with regarding record classes?

---

Previous suggestion, bubbling up

With the new Static Abstract Interface Members feature, it would be really nice to be able to "bubble up" the requirement through an abstract base class to an implementing class.

See the following simplified example:

public interface IAnimal
{
    static abstract string SpeciesName { get; }

    static abstract void Pet();
}
public abstract class AnimalBase : IAnimal
{
    // Bubbles up the requirement for the final animal to implement SpeciesName
    public static abstract string SpeciesName { get; }

    // Abstract class is providing a default implementation.
    public static virtual void Pet()
        => Console.WriteLine($"You pet the {SpeciesName}");

}
public sealed class Giraffe : AnimalBase
{
    // Must implement SpeciesName. base is not allowed.
    public static string SpeciesName => nameof(Giraffe);

    // Override the static default implementation.
    public static override void Pet()
        => throw new InvalidOperationException("You shouldn't pet a giraffe!");
}

I should be able to call Giraffe.SpeciesName and get "Giraffe", but another animal like Cat.SpeciesName would return a "Feline".

This echoes the existing behavior of if the IAnimal interface were applied directly to each animal type, but if you would like to provide some sort of common functionality (which arguably is the purpose of base classes), you run into a wall, namely CS0112 ("A static member cannot be marked as 'abstract'").

Workarounds

There are a few workarounds currently:

1. Create a new type, like AnimalService, that provides the shared functionality and avoid the abstract base type entirely.
2. Remove the static abstract marker from the IAnimal interface members and rely on instances.
3. Break out the static abstract interface member in question to a separate interface, then implement that on the final type, skipping it in the base class.
   • This assumes that none of the base functionality relies on that member.
   • You can no longer access that member by passing around AnimalBase

---

I'm sure there's a very good reason this has not been done before now, even if that's just "nobody has championed a solution for this," but I'm definitely interested in hearing any flaws or drawbacks with my design.

Amendment: I think this should only be allowed in classes marked abstract. Non-abstract classes should probably not be allowed to bubble up members, but I'm interested in hearing counter-arguments.

[TheBrambleShark]

Related to #9122

[jnm2]

I don't think so. The crux of what's being asked here is for classes to be allowed to have static virtual methods, whereas #9122 is about allowing a static class to implement an interface, which OP is not requesting here.

[jnm2]

Before there's any question of the automatic bubbling up of abstract static methods in class, the main thing is that the language does not yet allow abstract static methods in classes.

This is mentioned in [Proposal]: Static abstract members in interfaces:

Virtual static members in classes

Another additional feature would be to allow static members to be abstract and virtual in classes as well. This runs into similar complicating factors as the default implementations, and again seems like it can be saved for later, if and when the need and the design insights occur.

I skimmed all of https://github.com/dotnet/csharplang/blob/main/proposals/csharp-11.0/static-abstracts-in-interfaces.md#design-meetings for any discussion of this, but saw none. So, this may be the first request for static abstract/virtual members in classes. Randomly enough, I could have really used static abstract members in classes this past week.

[TheBrambleShark]

Do you think it's worth retooling my proposal to be primarily focused on the "virtual static members in classes" feature and making the bubbling up of members be an implementation detail of the main feature?

[jnm2]

I do! I expect the bubbling up to be a much riskier proposal, actually, and potentially possible to DIY via source generation.

[m-gasser]

So, this may be the first request for static abstract/virtual members in classes. Randomly enough, I could have really used static abstract members in classes this past week.

Whilst I never requested this, I seem to stumble over this quite a lot. I used workaround 3 in two places, and at least in one place workaround 2. A quick search in our code base showed that there are currently 16 usages of abstract interface members, where this abstract base class issue is not hit. Unfortunately I can't use code search to find out, how often developers tried to use abstract interface members but upon failing resorted back to instance members.