[Open issue]: static abstract interfaces and static classes

[stephentoub]

Champion issue: #9123

With static abstract interface methods, consider:

using System;

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

internal interface IMethods
{
    static abstract void M();
}

This compiles fine. However, if I try to make C be a static class:

using System;

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

internal interface IMethods
{
    static abstract void M();
}

it fails to compile with:

error CS0714: 'C': static classes cannot implement interfaces

Such an error arguably made sense before static abstract interface methods, as interface methods could only be instance members, and static classes can't have instance members (and even for an empty interface, you can't create instances of a static class and thus couldn't even use the interface as a typical marker used with is casts).

However, with static abstract interface methods, you can have an interface entirely composed of static abstract members, and it would logically make sense to have a static class implement that interface.

We could address this by either:

1. Simply removing the error and allowing static classes to implement interfaces. If you try to implement one that has instance members, you won't be able to given the class is static, and you'll get errors about not fully implementing the interface.
2. Allowing interfaces to be marked as static interface such that it can only contain static abstract members and not instance members, and then allow static classes to implement static interfaces.

One of the reasons one might want a static class implementing a static interface is to be able to then use that static class as a generic type argument. However, that is also prohibited by the language today, e.g. this:

using System;

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

class D
{
    public static void M1<T>(){}
    
    public static void M2() => M1<C>();
}

results in:

error CS0718: 'C': static types cannot be used as type arguments

We should also consider lifting this constraint.

If we do lift it, then it becomes possible for a generic type or method to create locals, fields, etc. of that generic type, which could be a static class. Those members or locals would then be useless, since you wouldn't have a way to create an instance of them nor invoke anything off of them. If that's something we want to avoid, we could go with option (2) above, allow static classes to be used as a generic type argument when that argument is constrained to a static interface, and then language rules around static types (extended from classes to interfaces) should naturally prevent creating such members and locals.

Design Meetings

https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-02-16.md#static-abstract-interfaces-and-static-classes

[CyrusNajmabadi]

Simply removing the error and allowing static classes to implement interfaces. If you try to implement one that has instance members, you won't be able to given the class is static, and you'll get errors about not fully implementing the interface.

I like this with one caveat. If the interface has no static members, you still get an error. So this would include an empty interface, as well as an interface with only instance-DIM methods.

Alternatively, we could say: interface needs to be non-empty and only contain static members to be implementable by a static class.

[stephentoub]

That seems reasonable.

[siegfriedpammer]

Alternatively, we could say: interface needs to be non-empty and only contain static members to be implementable by a static class.

Could even be a requirement to add the static modifier to the interface declaration?

[stephentoub]

Could even be a requirement to add the static modifier to the interface declaration?

I believe that's the option (2) I outlined 😄

[333fred]

For option 2, it seems like an unnecessary bifurcation to me, unless regular types can also implement so-called static interfaces.

[stephentoub]

unless regular types can also implement so-called static interfaces

Yes, they'd be able to. You'd just only be able to implement an interface on a static class if the interface was also static, but making the interface static wouldn't require that all implementors be static.

[333fred]

unless regular types can also implement so-called static interfaces

Yes, they'd be able to. You'd just only be able to implement an interface on a static class if the interface was also static, but making the interface static wouldn't require that all implementors be static.

I see. In that case, my gut reaction would lean towards option 2 for the intentionality of the design: otherwise, we introduce another way that you can silently break your users 😅

[reflectronic]

Considering that static classes cannot be used as generic type arguments today, how is this feature useful? Without the ability to do that, you cannot actually use an interface as an abstraction for a static class. This feature alone would not really get you anywhere.

[CryoMyst]

2 does seem like the better option here, allowing static interface which restricts instance implementations and restrict from generic type arguments.
Whilst reflectronic does make a good point where you can't actually use it for abstractions it is useful sometimes to enforce some sort implementations on a collection of static classes.

[stephentoub]

Considering that static classes cannot be used as generic type arguments today, how is this feature useful? Without the ability to do that, you cannot actually use an interface as an abstraction for a static class. This feature alone would not really get you anywhere.

I don't understand the point. Consider:
https://github.com/dotnet/runtime/blob/main/src/libraries/System.Net.Security/src/System/Net/Security/ReadWriteAdapter.cs#L11
which below it is then implemented by two types that only provide static members. Those types are then used as generic type arguments in order to parameterize what various static calls do, e.g.
https://github.com/dotnet/runtime/blob/e8fb8084e4667a0d95f1f41270617c09843df5fc/src/libraries/System.Net.Security/src/System/Net/Security/SslStream.Implementation.cs#L756
Right now those types are structs, but they can just as easily be classes, and as classes I'd want them to be static to get compiler validation that I don't accidentally add instance members to them, which is the whole point of being able to put static on classes.

(I'd also like the option of being able to put static on structs to get the same validation, but that's introducing a new concept and is a separate discussion.)

[naine]

This feature does make sense to have along with static abstracts in interfaces, but I agree that as is, the feature alone has no utility.

Those types are then used as generic type arguments in order to parameterize what various static calls do

If the implementing types were static, as this feature would enable, you would no longer be able to use them as generic type arguments, due to error CS0718.

To do this with a static class, the language would also have to be modified to permit static types to be passed as generic type arguments, most likely along with a new type of constraint to indicate what type parameters may be static and prevent the generic code from declaring a variable, field, or parameter of these type arguments.

[stephentoub]

the language would also have to be modified to permit static types to be passed as generic type arguments,

Yes

most likely along with a new type of constraint to indicate what type parameters may be static and prevent the generic code from declaring a variable, field, or parameter of these type arguments

Maybe. To me the utility of a static class isn't that it prevents me from declaring a useless instance (there are many other ways to achieve that), it's that as the creator of the type it helps me avoid problems by adding members to a type that shouldn't be there.

But if we went with option 2, then the language could permit static classes as generic arguments if the generic parameter was constrained to a static interface, and it could also ensure that variables, fields, etc. of such statics weren't created.

[TahirAhmadov]

I would vote for option 2. I think the intention part of it is important just for readability, but also for future maintenance - if somebody tries adding an instance member to that static interface, they are stopped from doing so immediately, and while yes they can just remove the static keyword, at least it's something that they have to do manually - there was a set of eyes who makes that decision. On the other hand, with option 1, an instance member is added, this project is built, then another project which relies on this project fails downstream all of a sudden.
Also, at runtime, with option 2, the binder can run a simple check and produce a concise error - interface not static - as opposed to option 1, where the binder has to inspect the surface area and produce a complicated error - interface implemented by static class now contains instance members.
Also, it's just one keyword to add on top of an interface, so it's not a crazy amount of typing in the big picture.

[siegfriedpammer]

Could even be a requirement to add the static modifier to the interface declaration?

I believe that's the option (2) I outlined 😄

Well... that's what I get for reading these proposals on my phone... my bad...

[Joe4evr]

You'd just only be able to implement an interface on a static class if the interface was also static, but making the interface static wouldn't require that all implementers be static.

🍝 Would it be plausible to also allow ref structs to implement such a static interface? If the definition of a static interface disallows callers to create instances of its implementers anyway, then I think the dangers of boxing a ref struct instance through said interface no longer apply.

I admit I haven't thought up a use-case for it, it's just something that came to mind.

[333fred]

Extremely unlikely.

[brantburnett]

I really like this proposal, but I'd like to add one additional thought around option 2.

Since a static interface can't contain instance members, logically it is little more than just a list methods required to be implemented. Other than clear "documentation" on an implementing class, it's primarily useful within generics. You wouldn't be able to typecast to it like you can a traditional interface.

Therefore, wouldn't it be possible for the C# implementation to be shape-based, like TypeScript interfaces rather than traditional C# interfaces. This would allow any class that implements all of the static methods to be considered as matching a generic constraint on the interface, not just classes that explicitly implement the interface. This could be useful in cases where the static method signatures are matched by a 3rd party library not under the developer's control.

[ds5678]

If anti-constraints like allow T : ref struct are being introduced into the language, could there be resources to concurrently do allow T : static?

[jnm2]

@ds5678 I think I'd rather just allow static types to be passed as type parameters everywhere. We already have a very similar situation:

public abstract class BasicallyStatic
{
    private BasicallyStatic() { }
}

new List<BasicallyStatic>() // Where's the danger in this?

To the runtime, there aren't static types, only abstract sealed types.

[jnm2]

If a static class can implement an interface, it seems interesting to allow a static class to inherit another static class.

static class Shape : IShape { ... }
static class Circle : Shape, ICircle { ... }

[ds5678]

I think I'd rather just allow static types to be passed as type parameters everywhere.

@jnm2 It does have inherent flexibility and brevity. Those are large benefits that cannot be ignored.

However, it changes the mental model for what a static class is.

ActuallyStatic? local = null;
List<ActuallyStatic?> list = [ local ];

Previously, locals and expressions could not be typed as a static class because such classes could never have instances. Now, we would have to choose between making these methods uncallable or allowing static classes to be a valid target type.

Using an anti-constraint would indicate intent. The compiler could issue errors when a developer attempts to use the generic type argument in an invalid way.

[ds5678]

If a static class can implement an interface, it seems interesting to allow a static class to inherit another static class.

Although intriguing, I don't think this should be done because changing a static class to an an instance class is not currently a breaking change.

[HaloFour]

Previously, locals and expressions could not be typed as a static class because such classes could never have instances.

Would that need to change? You can coax the runtime to create a List<ActuallyStatic> or ActuallyStatic anyway. Heck, you can force it to create instances through reflection as well. The compiler can keep it's somewhat loose guardrails, while also removing this one limitation.

My concern is that by adding static interfaces that can only be implemented by static classes and can only be used as generic parameters with a static anti-constraint is that it creates needless bifurcation, which could lead to unnecessary friction.

[ds5678]

Speaking of breaking changes, I think we should allow static classes to inherit from interfaces with instance members, as long as all those instance members have default implementations. This allows breaking change rules for interfaces to stay the same.

[ds5678]

My concern is that by adding static interfaces that can only be implemented by static classes

Why wouldn't an instance class be able to inherit from a static interface?

[jnm2]

@ds5678

However, it changes the mental model for what a static class is.

I don't think it'll have a big effect in practice. The compiler can outright tell you you won't be able to use a member with a signature that includes that type parameter when the type parameter is a static class.

Although intriguing, I don't think this should be done because changing a static class to an an instance class is not currently a breaking change.

It could potentially not be a breaking change.

Why wouldn't an instance class be able to inherit from a static interface?

This is Steve's option 2 in the original proposal. The reason to have a static keyword for interfaces would be to make that be the declaration of intent around which everything hinges, instead of dynamically recognizing that a static class could implement that interface. If this option was taken, it would be following the same rationale as not having method return types be inferred from the return statements in the body. Declarations of intent provide an easy way to see what external usages will be supported and to explicitly notice and decide before changing that support.

[hamarb123]

Just thought I'd mention some uses that I'd like to be able to write:

static void X1<T>() where T : allows static => ...;
X1<Console>(); //an example type

interface I { /*some static members allowed here*/ } //"static interface?"
static class C : I { }
struct S : I { }
static void X2<T>() where T : allows static, I => ...;
X2<C>();
X2<S>();

X1 would allow for any type that is allowed today + static classes (and ref structs could also be allowed if they're not implicit with another allows). This would be extra useful for when we get generic bridges, e.g., so that we can bridge to a static interface that we check later.

X2 would allow any type that implements the interface, including static classes (since all the members of the interface are static). I think it would be a massive shame if we disallowed non-static-classes to implement them though, since any type can have static members, and I shouldn't have to move my implementation to another type if I don't think it's appropriate in my situation, just so I can allow a static class to implement it in another situation (nevermind the lack of generic specialisation, which is also an issue that would probably often encourage me to use structs anyway).

[molinch]

This would help tremendously for scenarios where you want to inject an ILogger where T is a static class.
As of now that ain't possible and you need to resort to LoggerFactory.

[mikernet]

@molinch Not sure I follow. Can you demonstrate how this would help in that scenario?

This doesn't let you do anything you can't already do by just not marking the class static. Usage of the static interface would be the same.

[molinch]

@mikernet This proposal would allow to define an ILogger where Whatever is a static class.
Currently the solution is to rely on the LoggerFactory, which works but is a workaround until having it improved at language level.

See the first message from Stephen