[Open issue]: static abstract interfaces and static classes

[stephentoub]

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 :sweat_smile:

[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.

[FaustVX]

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

In your example, what the generic constrain could be ? May be something like that :

public static void M1<T>() where T : static {}

But with that kind of constrain, we should still be able to use normal classes.

[stephentoub]

In your example, what the generic constrain could be ?

My example would be augmented to instead be like:

using System;

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

static interface I
{
    static void M();
}

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

[FaustVX]

Ok, so interfaces are needed to do generic with static classes ?

[jnm2]

Allowing static classes to implement interfaces which only have static members, and to be passed as generic type arguments, was first discussed at https://github.com/dotnet/csharplang/issues/4436#issuecomment-946729152. There's also discussion on just the generic type argument part at https://github.com/dotnet/csharplang/discussions/4840 and https://github.com/dotnet/csharplang/discussions/5517.

Allowing interfaces to be marked static with the effect of requiring all its members to be static was first discussed at https://github.com/dotnet/csharplang/issues/4436#issuecomment-797151352

[Richiban]

I like the ability to declare static interfaces from Option(2), but I'm not sure I would go with the limitation that static classes can only implement static interfaces.

I can totally see a situation where a library has published an interface with all static members (probably a single member, which is static) but the author hasn't marked the interface as static. You've got a static class that you want to pass as a type argument to some method so you need implement said interface but you can't; you're completely SOL.

[jnm2]

@Richiban Unless you make the static class non-static. If I understand right, that's the price we'd pay in order to avoid adding this new way that it would be a breaking change to add an instance member to an interface (DIM or not).

[jeffhandley]

@MadsTorgersen / @stephentoub / @tannergooding -- Is there anything remaining open on this, or can this issue be closed out?

[tannergooding]

This is an issue tracked by the C# LDM team, so they're responsible for tracking it and closing it.

The support requested by the feature doesn't currently exist but is championed so it likely needs to stay open.

[333fred]

We don't close issues until they are implemented in the ECMA spec.

[zvrba]

The following (somewhat paradoxically) does not work in net6 with preview features enabled:

interface IStatics {
    public abstract static int AI { get; }
    public static int CI => 14;
}

static int M<T>() where T : IStatics {
    return T.AI + T.CI;  // ERROR
    return T.AI + IStatics.CI;  // WORKS
}

The compiler complains on T.CI. The second return statement compiles fine. I see no reason why the first variant should not be allowed, so this is perhaps an oversight in the spec?

Yes, the workaround is simple, but it'd be nice to be able to write the body of M only in terms of its generic parameter instead of switching between T and IStatics depending on whether the method is abstract or not. Not to mention that, if it worked, it'd be possible to change CI to abstract at a later point without changing the implementation of M.

EDIT: Re possible ambiguity if T has its own static definition of CI: use definition from the interface (most intuitive, at least for me, as T : IStatics is the only thing known about T; perhaps a warning should be issued) or make it an error (also intuitive; if overriding is desired, the member should be declared as abstract in the interface). Though I don't know how to handle M being instantiated through reflection in this case. The first behavior (use definition from the interface) is probably the only feasible one.

[En3Tho]

In your example CI is not abstract, it's a legit static member of that interface. You have to make this thing static virtual to get it working from T.

[zvrba]

In your example CI is not abstract, it's a legit static member of that interface. You have to make this thing static virtual to get it working from T.

This does not answer the original question: why the compiler can't (or won't) look up and bind to CI through T when T is declared as T : IStatics To me, this is a deficiency/oversight in design of the feature.

[En3Tho]

Because CI is a direct static member of that interface, it's not a part of interface contract.

[tannergooding]

It’s worth noting that static members are “inherited” and accessible from the derived type in other cases.

System.Runtime.Intrinsics relies on this to help model the “dependency hierarchy” between the various ISAs exposed. Thus, Sse2 inherits from Sse, and each only exposes static members. But Sse2.Sqrt(Vector128<float>) is still valid even though Sse is what defines/exposes that static method.

It’s, IMO, reasonable to expect this very similar situation where T is known to derive from the interface to therefore have access to static members defined by the interface (and for it to ultimately give the IDE hint that it can be simplified down to directly accessing the member form the interface, just as it does for the other described above)

[c0nd3v]

@stephentoub I think this should be finalized for .NET 7/C# 11😃