Proposal: Static entities in interfaces

[prasannavl]

Currently, static items aren't allowed in interfaces. This is not a technical limitation, rather a semantic one that it doesn't make sense to have it. However, this was a decision that was made before Generics.

There are many uses case that it'd make immensely better, if present, both with and without generics. For example, there's really no way currently to allow generics to work with operator overloads.

Example: Use Case 1

public static void Add<T, U>(ref T src, ref T target)
where T: IRectangle<U> 
where U: IOperatorPlus<U>
{
  src.Left += target.Left;
  src.Right += target.Right;
  src.Top += target.Top;
  src.Bottom += target.Bottom;
}

This is a surprisingly simple code, that just won't work today. If you have IRectangles, that take short, int, float, decimal, for example, there simply is no other way than to write very redundant code for each class over and over again.

However, allowing static in interfaces would allow this very naturally.

The definition of the IOperatorPlus would look something like this:

interface IOperatorPlus<T> {
 public static void operator+(IRectangle<T> source, IRectangle<T> target);
}

Example: Use Case 2

Statics in interfaces would also be very useful in cases, where you can write code that depends on having contractually defined static methods.

public class X : IStaticFactory {
  public static IX Create()
   {
    return X(new DefaultY());
   }
  public X(SomeDependency IY) { }
}

interface IStaticFactory 
{
 static IX Create();
}

This is a pattern that would allow a high-performance constructor, for many different classes that implement the IStaticFactory, without relying on Activator which uses reflection. This also includes the generic construction new T().

Static entities in interface allow scenarios such as this to be enabled, instead of jumping through hoops.

[HaloFour]

This is a dupe of #2204.

While the CLR does allow for interfaces to contain static members it has no concept of virtual static members. There is no static or type-wide vtable through which to virtually dispatch a method call. As such it's not possible to define required static members of an interface, only completely concrete members.

[prasannavl]

@HaloFour,
Scenario 1 - the resolution for all this can be done in compile time. So, v-table should be irrelevant.
Scenario 2 - I think you're spot on there. That's a challenging scenario on how to implement.

However, sorry about the duplication. Not sure how I missed in the search. Closing this.