Proposal: Static Interfaces

[Whiteknight]

I'd like to propose the idea that we could specify static methods using interfaces. Since this really would be semantically distinct from the purpose of ordinary interfaces, a syntax like this would suffice:

static interface IFactoryMethod<T> {
    T Create();
}

The primary use I have in mind is that you would be able to use this with type constraints to allow working with static methods more convenient:

T Create<T>() where T : IFactoryMethod<T> {
    return T.Create();
}

This would be useful for any case where we expect multiple classes to implement common behavior that does not require an instance to be created first.

[diab0l]

This is somewhat related to the traits ideas and similar and I am all in for it.

Although I have to say a better example is required:

• The caller of the generic Create<T> method would have to specifiy the type argument T explicitly since there is no context to infer it
• The caller has to supply a T which satisfies the constraint IFactoryMethod<T>
• So at the point of the caller, the type she would suppy for T in Create<T> (let's call it Foo) has a callable Create method
• So the caller could always call Foo.Create() instead of Create<Foo>()

which makes the whole concept moot.

[diab0l]

Also, if we go for static interfaces, it is mandatory that we go for static abstract types as well.

[HaloFour]

There was a wider discussion along these lines on CodePlex about expanding the generic type constraints to support requiring that the generic type argument support specified methods. Of the primary goals was to support constraints based on overloaded operators which are just static methods.

Either way you're looking at CLR changes as interfaces can't express required static fields (who owns the vtable?) and generic type constraints can't express specific required methods.

[diab0l]

Well, you can work around that problem and punch static virtual types into the current CLR design.

You could simulate a static virtual method with a virtual method.

public static interface IFactory<T> {
    static T Create();
}

public static class Factory<T> : IFactory<T> {
    public static T Create() { ... }
}

public class Program {
    public static TType Create<TFactory, TType>() where TFactory : IFactory<TType> {
        return TFactory.Create();
    }

    public static Main() {
        var foo = Create<Factory<Foo>, Foo>();
    }
}

could be translated to

// compiler generated, marked to be "pseudo-static"
public interface IFactory<T> {
    T Create();
}

// compiler generated, hidden with metadata or something
public class StaticImpl__Factory<T> : IFactory<T> {
    public T Create() {
        return Factory<T>.Create();
    }
}

public static class Factory<T> {
    public static T Create<T>() { ... }
}

public class Program {
    public static TType Create<TFactory, TType>() where TFactory : IFactory<TType>, new() {
        return new TFactory().Create();
    }

    public static Main() {
        var foo = Create<StaticImpl__Factory<Foo>, Foo>();
    }
}

I do have to admit that this looks horrifying and I am sure there is a better encoding with less perverse transformations, but technically it's possible to do this at a language-level by piggy-backing on the existing new() constraint (the only structurally matched constraint?) and actual virtual types.

[TwoRedCells]

Looks a lot like Issue #154.

[diab0l]

@TwoRedCells The goals are the same, but currently that template proposal is "static interface + static abstract type" collapsed into a single feature, whereas static interfaces are distinct from static abstract types.

Not that it matters. Before any of this becomes reality, we need either an extended CLR or an extensibility model for the CLR's common type system.

[ghost]

Adding reference to @thinkbeforecoding's old blog article on advantages of static interface feature: http://thinkbeforecoding.com/post/2009/10/21/CSharp-Static-interfaces.

[gafter]

We are now taking language feature discussion in other repositories:

• https://github.com/dotnet/csharplang for C# specific issues
• https://github.com/dotnet/vblang for VB-specific features
• https://github.com/dotnet/csharplang for features that affect both languages

Features that are under active design or development, or which are "championed" by someone on the language design team, have already been moved either as issues or as checked-in design documents. For example, the proposal in this repo "Proposal: Partial interface implementation a.k.a. Traits" (issue 16139 and a few other issues that request the same thing) are now tracked by the language team at issue 52 in https://github.com/dotnet/csharplang/issues, and there is a draft spec at https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md and further discussion at issue 288 in https://github.com/dotnet/csharplang/issues. Prototyping of the compiler portion of language features is still tracked here; see, for example, https://github.com/dotnet/roslyn/tree/features/DefaultInterfaceImplementation and issue 17952.

In order to facilitate that transition, we have started closing language design discussions from the roslyn repo with a note briefly explaining why. When we are aware of an existing discussion for the feature already in the new repo, we are adding a link to that. But we're not adding new issues to the new repos for existing discussions in this repo that the language design team does not currently envision taking on. Our intent is to eventually close the language design issues in the Roslyn repo and encourage discussion in one of the new repos instead.

Our intent is not to shut down discussion on language design - you can still continue discussion on the closed issues if you want - but rather we would like to encourage people to move discussion to where we are more likely to be paying attention (the new repo), or to abandon discussions that are no longer of interest to you.

If you happen to notice that one of the closed issues has a relevant issue in the new repo, and we have not added a link to the new issue, we would appreciate you providing a link from the old to the new discussion. That way people who are still interested in the discussion can start paying attention to the new issue.

Also, we'd welcome any ideas you might have on how we could better manage the transition. Comments and discussion about closing and/or moving issues should be directed to #18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.

The feature requested here would be satisfied by the addition of type classes to the language; see dotnet/csharplang#110