Why are we unable to add non-generic extension methods to generic objects?

Question

I finally got tired of IEnumerable not having an Add method, and decided to add my own through an extension method. My initial attempt was something along these lines:

public static void Add(this IEnumerable<T> items, T item)
{
    ...
}

This threw the expected compiler error about T not being defined, so I changed the signature to Add<T> to define it. (For explanation, see this answer.)

However, this got me thinking. If we create a generic class on our own (like IEnumerable<T>), we are able to add methods to it like the one I had originally tried because T is defined in the class.

I understand that extension methods are not created as a part of the class. There is no "magic" that happens in the compiler to add them to the original class.

I would still think that because of the this declaration on the initial parameter, that the <T> in that parameter could be used to define the type for the method.

My question is this:

Why is there that limitation when it comes to extension methods? Is there something that has been explained for this limitation? Is it something that could be proposed to the language team and added in a future release?

To be more specific, Jonsey reiterated my point a bit more eloquently:

I think I get what you're asking. Why is the compiler not smart enough to recognize, given the method signature, that T is already declared, and doesn't really need to be in the signature?

EDIT

I should have used my new method (Add<T>) before posting as I discovered that when using the method, I don't have to call it generically, I can just use .Add(). I guess that goes along with this answer. I still just find it odd the way it has to be declared, and perhaps that adds a twist to the entire situation.

Argument against duplicate of this question The mentioning of creating IEnumerable<T>.Add() is for illustrative purposes only of the reasoning behind me finding this "peculiarity", and my question is more generic, not specific to that one method.

Answer 1

Well, you need to ask yourself what's special about T here. Suppose we were to write:

public static void Add(this IEnumerable<X> items, X item)

... would you expect that to work? If so, consider:

public static void Add(this IEnumerable<Button> items, Button item)

Would you expect that to mean the same thing, i.e. effectively be a generic method taking any sequence, or actually only make sense for an IEnumerable<Button> where Button is the System.Windows.Forms.Button class or whatever an appropriate using directive indicates?

Basically, the compiler needs to look up what T means. That can be:

• A type parameter in the declaring class
• A type parameter in the declaring method
• A normal type lookup

In your case, you're in a non-generic class and a non-generic method, so it falls back to a normal type lookup which fails.

Basically you want this to be a type parameter, so it has to be a generic method (or class, but extension methods aren't allowed in generic classes).

If you don't think that the first example (with X) should work, then presumably you're expecting T to be looked up in the context of the IEnumerable<> type, which makes things even odder, as it means that type parameter names become important from "client" code in a way that they aren't anywhere else in the language. It also makes other things tricky. For example:

static void Add(this IEnumerable<T> items, Dictionary<T, T> dict)

Here T is valid for IEnumerable<T>, but Dictionary<,> has TKey, TValue... so should the compiler just say that IEnumerable<T> wins? It ends up being much more confusing than just saying "No, if you want a generic method, you have to declare a type parameter."

Answer 2

You can, you just need to tell the compiler what T is since it doesn't understand it in the context of an extension method.

public static void MyAdd<T>(this IList<T> items, T item)
{

}

When you use it, it will infer the type from the item, for example:

List<string> myList = new List<string>();
myList.MyAdd("this is added to the string");

It looks a little strange in Intellisense because it includes the <> after the name, but you don't have to use it, it will infer the type by itself.

As the other comments say, IEnumerable<T> is an interface, not a class, and you can't Add to an IEnumerable, so your original post doesn't make sense to add an "Add" extension method to something thats not really a collection. But if you were using a collection, like IList, then it works just fine.

Answer 3

I would still think that because of the this declaration on the initial parameter, that the in that parameter could be used to define the type for the method.

Why?

Let's say you have this method:

public void Foo(int i1, T item)
{
}

should the compiler auto-detect the T and translate it to:

public void Foo<T>(int i1, T item)
{
}

and let's say you have

public void Foo(int i1, T1 item1, T2 item2)
{
}

should the compiler translate it to?

public void Foo<T1, T2>(int i1, T1 item1, T2 item2)
{
}

or to

public void Foo<T2, T1>(int i1, T1 item1, T2 item2)
{
}

Now, with extension methods it is the same problem. There is no reason why the T "this" generic argument should be first...

public static void Foo<T2, T1>(this IEnumerable<T1> enu, T2 somethingelse)
{
}

It is only a convention.

Answer 4

At the moment, all the compiler has to do when it's compiling a static method inside a static class and observes that the first parameter is preceded by this is that it has to emit the ExtensionAttribute on this method. Otherwise, it continues to parse/compile this method in exactly the same way as it would any other (non-extension) static method.

Under your proposal, it has to radically alter it's parsing rules in this one specific place, and it makes the language less consistent. I wouldn't describe it as a limitation, more of a logical consequence of how language features work together.