24

Possible Duplicate:
extension method requires class to be static

In .NET:

Why can't static method in non-static class be an extension method?

Community
  • 1
  • 1
Yaakov Shoham
  • 10,182
  • 7
  • 37
  • 45
  • 1
    I would imagine it's in how the method is wired. Extension methods are never actually attached to their target classes. That's compiler/IDE magic. They belong on their own, separate class. For this to work, the framework would need to create a new instance of the "extension" class every single time the target method is called. I don't personally know how they plumbed up extension methods, but I can see where this would be problematic. Leaving as a comment, hopefully someone has the definitive answer on this one... – Pete M Sep 13 '11 at 17:15
  • Found it was a dup looking for an Eric Lippert quote =) – Ed S. Sep 13 '11 at 17:22
  • Because Microsoft said so. Maybe other reasons surround the issue of turning someone's library against them, as it changes into a mutated code zombie. What you "want" is risky for companies that provide 3rd party solutions (PDF generation etc.), and sneaky developers can do things they shouldn't be . Extension method are to extend the class, not give you full control over the innards of it. – Ryan Ternier Sep 13 '11 at 17:24
  • 3
    @Pete Static Functions don't require an instance of a non-static class to exist. – Michael Stum Sep 13 '11 at 17:27
  • 1
    TL;DR there is no technical reason. It was a design decision. – snarf May 27 '19 at 18:01

4 Answers4

35

Eric Lippert will probably weigh in with a really good answer on this one, but the gist of it will probably be:

We decided it would be easier on both programmers and the compiler if we limit the number of places that you have to look for extension methods.

This policy tends to force users to put all of their extension methods into a few specific classes that are designated for this purpose.

StriplingWarrior
  • 151,543
  • 27
  • 246
  • 315
  • 19
    Just seems an arbitrary restriction to me. Extension instance methods are syntactic sugar, not reason why static methods could not have been sweetened a little. – Miserable Variable Sep 13 '11 at 17:17
  • Of course there is a reason; every feature has a cost. What is the utility of this feature to us as programmers? – Ed S. Sep 13 '11 at 17:18
  • You used the "quote" formatting for quoting yourself! :-) It's... It's... Immoral! But I think it's so (the gist...), so it's +1 :-) – xanatos Sep 13 '11 at 17:18
  • It isn't arbitrary at all ... – IAbstract Sep 13 '11 at 17:20
  • 4
    @Hemal: I think extension methods needed just a dash of arbitrary restriction. It keeps syntactic sugar from being used like syntactic cocaine. – StriplingWarrior Sep 13 '11 at 17:21
  • @Xanatos: Hehe, I'm, um, quoting my imaginary version of Eric Lippert. ;-) – StriplingWarrior Sep 13 '11 at 17:23
  • @Ed I fail to understand what benefit being able to say `o.Foo()` provides over `X.Foo(o)` (where Foo is extension method) such that same benefit would not also be provided by being able to call `C.Bar()` over calling `X.CBar()` – Miserable Variable Sep 13 '11 at 17:24
  • @Hemal: I think you're confusing this question with http://stackoverflow.com/questions/4909156/why-arent-c-static-class-extension-methods-supported, which is a different story altogether. The OP just wants to know why he can't have his public static method be an extension method if it's not on a static class. – StriplingWarrior Sep 13 '11 at 17:30
  • 2
    @Hemal: The benefit is that instance level extension methods are more natural and convenient, and they were needed to make LINQ work. Static extension methods were not required to make LINQ work. This is a duplicate question, read the original and Eric Lippert's response. – Ed S. Sep 13 '11 at 17:32
  • @StriplingWarrior: No, the question is *slightly* different, the answer is the same. – Ed S. Sep 13 '11 at 17:32
  • 1
    @Ed thank your for pointing me to that. I get the point now, Extension methods were added to make LINQ work. LINQ did not need static extension methods so they were not added. My work -- porting some client code to a new version of an API -- would have been easier if both instance and static methods could be defined as extensions, so I rue the absence of static extension methods. Make sense? – Miserable Variable Sep 13 '11 at 17:35
  • @Hemal: Sure, that's fair enough. I'm not saying that it would be a bad feature, I am just trying to express why they weren't implemented in the first place. – Ed S. Sep 13 '11 at 17:36
  • @Ed, yes...that's exactly what I meant when I said I get the point. Things are done for a purpose and there are always priorities. I wasn't being sarcastic or such. I sincerely meant it :) – Miserable Variable Sep 13 '11 at 17:39
  • Extension methods shouldn't belong to a new object, they should belong (atleast seemingly) to the original, I think that is the main reason. It would confuse things because extension methods are intended to be invoked off the first parameter of the function, not the object declaring the function as is normally the case. – Sean Thoman Sep 13 '11 at 17:43
  • @Jason: They were needed *to make LINQ work in the way the designers wanted it to work*. I don't see anyone here stating that an instance is required to call a static method. You are just reiterating what has already been said; no, there is no *technical* reason that they don't exist, there is simply a practical reason. – Ed S. Sep 13 '11 at 18:26
  • 9
    The "gist" you've come up with is a pretty good summary, plus as Ed points out, almost all features that were not necessary to make LINQ work got cut. – Eric Lippert Sep 14 '11 at 00:55
  • Its an answer but not a very satisfactory one somehow. With Intellisence and code navigation features in IDE, would it really be so hard to find the methods? – shivesh suman Jun 06 '20 at 08:41
1

Because, well, that's the way it is.

My guess would be that allowing static extension methods would complicate the language (every feature adds complexity of one type or another) while adding almost zero benefit. If you are defining a static method on String for example, what's the benefit in doing so when you can simply define your own class with the same static method?

Instance level extension methods are useful because they work on the current state of a type instance. The static method has no context, so it would not provide any utility over a static method defined elsewhere aside from logical grouping (i.e., defining a String.IsNullOrFullOfSomeChar(char c) would logically make sense to belong to the String class, but aside from that there is no advantage. And yes, that would be a horrible method, just an example).

Extension methods came about as a result of LINQ. They were implemented to get LINQ working the way that the designers wanted. Static extensions were not required and, as such, they were not implemented.

Ed S.
  • 122,712
  • 22
  • 185
  • 265
  • 1
    NB before you start reading, this answers the [wrong question](http://stackoverflow.com/questions/4909156/why-arent-c-sharp-static-class-extension-methods-supported) - see StriplingWarrior's answer below for an educated guess – Alex Nov 23 '15 at 14:59
1

It makes sense that a static class is required to have extension methods. The number one reason is that the static class is stateless ...i.e. you don't have to instance the class. ...but this is just my gut feeling. It wouldn't make sense to me otherwise.

I think, too, that forcing extension methods to reside in public/internal static classes reduces the cost of using them.

IAbstract
  • 19,551
  • 15
  • 98
  • 146
  • You don't need an instance to invoke a static method. – jason Sep 13 '11 at 17:23
  • @Jason - I didn't say you need an instance to invoke a static method. It just wouldn't make sense to have `public static void ExtMethod(this whatever)` in an instance class ... – IAbstract Sep 13 '11 at 17:26
  • 2
    Why doesn't that make sense? I'm looking at you `String.IsNullOrEmpty`. – jason Sep 13 '11 at 17:27
  • I don't know why the 2 downvotes but I'll try to make up for 1. – Miserable Variable Sep 13 '11 at 17:31
  • 1
    IMO, many classes and primitive types would look much different if extension methods had been part of .Net from the beginning: `myStrVar.IsNullOrEmpty()` – IAbstract Sep 13 '11 at 18:25
  • 2
    @IAbstract: Actually, that could have been handled even more cleanly by allowing non-virtual methods to be explicitly declared as "null-accepting". BTW, one thing that peeves me about extension methods is that there's no way for a class *or interface* to declare extension methods on itself, and have those methods obey the same rules of scope as the class or interface. – supercat Nov 18 '11 at 00:08
-1

At compile time whenever you use the instance syntax sugar for extension methods, this is converted into a call to the static method (which defines the extension), and passes through your instance.

Apart from the nice syntax it's no different to implementing a static method and passing your instance through as an argument. This is exactly what happens. You can't do this with static classes, as you can't pass a static class as a parameter to a method.

TheCodeKing
  • 19,064
  • 3
  • 47
  • 70
  • This isn't relevant to the question asked. You're arguing about extending static classes. – chase Dec 05 '13 at 08:54
  • Actually I'm answering the question of why extension methods cannot work with static classes. The answer is because extension methods are compiled into static methods that cannot recieve a reference to a static class. – TheCodeKing Dec 07 '13 at 12:22