Is the CLR capable of static interfaces?

Question

And if so, why can't you do this:

public interface IParsable
{
    static IParsable Parse(string s);
    static bool TryParse(string s, out IParsable);
}

in C#?

EDIT: Or, alternatively:

public interface IParseable<T>
{
    static T Parse(string s);
    static bool TryParse(string s, out T);
}

EDIT #2: I have learned the folly of my ways by trying to use an IParsable, as suggested by many below. The example I made follows. Of course, there is no way to resolve the call to TryParse...

public IParsable ReadFromKeyboard()
{
    IParsable ToReturn;
    bool FirstTry = false;
    bool Success;
    do
    {
        if (!FirstTry)
            DisplayError();
        AskForInput();

        Success = IParsable.TryParse(Console.ReadLine, out ToReturn);
        FirstTry = false;
    } while(!Success)

    return ToReturn;
}

Answer 1

No, you can't force a class to implement static members.

Answer 2

No, you cannot for a class to implement static methods. There's a simple reason for this:

An interface allows you to define behavior for an instance of an Object. Static Methods don't belong to an instance of an Object, they belong to the type. Therefore, defining static methods in an interface really doesn't make sense.

Answer 3

No, the CLR isn't capable of static interfaces. It would be a handy feature to have, but you instead need simulate it with either regular interfaces or reflection.

Other similar features that .NET (well, C#) doesn't have: Haskell type classes, F# member constraints on generic types

Answer 4

No, the CLR doesn't have such a thing as static interfaces. I've surmised that they'd be useful for generic type constraints, but that's the only use I can see for them... otherwise how would you use IParsable in your example? How would you pass around the type that was able to parse it?

See this blog post for more details of what I was envisaging.

Answer 5

The CLR doesn't support this. This is by design.

It has been suggested before - And if you read the comments there, you'll see that there are already some type-level contracts in place in the CLR (such as constraints on generics).

However, interfaces are really not the correct level for this, since they (by design) have a specific meaning: they describe a behavior contract for an object. Trying to add the ability to describe a contract for a type would be changing the meaning of interfaces.

Answer 6

The C# language syntax hides it, but a key properly of an interface method implementation is that it is a virtual method. It is hidden, you don't actually use the virtual (or overrides) keyword when you write the implementation method.

It has to be virtual, that's how interfaces are implemented under the hood. When you cast an object to an interface type, the runtime generates a pointer to the virtual method table section that contains the pointers to the interface method implementations.

What follows, given that virtual methods are the polar opposite of static methods, is that an interface declaration can never contain a static method. Static methods don't have method table entries.