Home > .NET, Design > Extension Methods and Static Generic Classes

Extension Methods and Static Generic Classes

This post refers to a question on Stackoverflow that I tried to answer a while ago and that still hasn’t received an accepted answer: Why is it impossible to declare extension methods in a generic static class?

Against popular belief, static generic classes are not a problem here, they are perfectly legal but not for declaring extensions methods. The original motivation of the person asking this question was to declare a static generic class defining a constrained generic type parameter once, so the constraints wouldn’t have to be repeated on each declared extension methods.

Consider the following extensions methods:

public static class ExtensionsForIMyInterface
{
public static void DoSomething(this IEnumerable source) where T : IMyInterface {};
public static void DoSomethingElse(this IEnumerable source) where T : IMyInterface {};
}

The purpose of this class is to provide extension methods for all types implementing IMyInterface. As you can clearly see, this constraint has to be repeated on every extensions method. If declaring extension method inside static generic classes would be allowed, we could add easily avoid repeating the constraint:

public static class ExtensionsForIMyInterface where T : IMyInterface
{
public static void DoSomething<T>(this IEnumerable<T> source) {};
public static void DoSomethingElse<T>(this IEnumerable<T> source) {};
}

But we can’t, so what’s the reason for this constraint?

Gorpik made a good point by mentioning that it would prove difficult for the compiler to locate non-generic extension methods on a static generic class. This would be the scenario:

static class GenStatic<T>
{
static void ExtMeth(this Class c) {/*...*/}
}

Class c = new Class();
c.ExtMeth(); // Equivalent to GenStatic.ExtMeth(c); what is T?

This is probably the best justification for the constraint because allowing the declaration of extension methods on static generic classes would make it necessary to constrain those classes to declare generic methods only. Adding yet another special case to provide a little syntactic sugar would pollute the cleanliness of the language design.

Advertisements
Categories: .NET, Design
  1. binki
    January 22, 2015 at 21:52

    Sorry to nitpick, but I’d just like to point out that the syntax of declaring a constraint in the class declaration while not declaring the class as a generic is wrong. Not only should you be able to save typing the constraint out every method declaration, you should (and the compiler forces you to!) avoid retyping for each method.

    It would be very cool if type inference were able to be combined with generic extension methods. Then you could do something like:

    public static class MyExtensions
    {
    static Lazy TypeSpecificProcessor = new Lazy(
    () => new HeavyWeightLinqExpressionsCompilerThing.Compile());

    public static U Process(this T o) { return TypeSpecificProcessor.Process(o); }
    }

    Being able to do something like this would be much nicer than having to manage a Dictionary—instead, the CLR’s generic static class initialization stuff would keep the mapping for me. That’s just what I’d use it for.

    However, I can understand one good reason for this to be disallowed: you could rewrite a lot of the existing extension methods that rely on type inference to use type inference at the class level. Giving developers two ways of accomplishing a task means that both ways will be used, making it someone confusing ;-).

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: