36

Why are extension methods only allowed in non-nested, non-generic static class? Is it useless to consider extension methods in nested, generic static class?

Second Person Shooter
  • 14,188
  • 21
  • 90
  • 165

3 Answers3

60

Why are extension methods only allowed in non-nested, non-generic static class?

As Pratik points out, the question we face is not "why are extension methods not allowed in nested or generic classes?" The question we face as language designers is "why should extension methods be allowed in nested or generic classes?"

Unless the feature is justified by some real-world user need, we're not going to take on the considerable costs of designing, implementing, testing, documenting and maintaining the feature.

Basically, extension methods were designed to make LINQ work. Anything that didn't contribute to making LINQ work was cut. LINQ only needs extension methods in static, non-generic, non-nested classes to work, so that's what we designed and implemented.

If you have a scenario where extension methods would be useful in non-static, generic, or nested classes then I'm happy to take a look at the scenario. The more real-world scenarios we get, the more likely it is that we'll make a feature in some hypothetical future language that benefits those scenarios.

Is it useless to consider extension methods in nested, generic static class?

No, it is a great idea to consider it. We would be remiss in our duties if we did not consider it. We considered it carefully for a long time and decided that on the basis of that consideration, the costs of doing the feature were not justified by the benefits accrued.

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
  • 1
    possibly my question which is essentially a dup of this one provides a real world example (?)... http://stackoverflow.com/questions/11443842/why-not-allow-extension-method-definition-in-nested-class – Aaron Anodide Jul 12 '12 at 01:38
  • 44
    IMO this was a very short sighted choice. Or the choice was misguided to not allow me to declare an extension method directly inside a normal C# class. There's so many times I want a local usage of foo.ToBar() extension method, that has no relevance outside of the class. – Chris Marisic Aug 15 '12 at 19:47
  • 1
    @EricLippert thanks for the clear explanation. To add to the "Real World Use Case" list: We have enumerations of values coming through from a third party source. For each third party source, we have private enums in our corresponding adapter class that deals with that source (hiding the specifics from the rest of our application). Externally, the application uses a different, consistent Enum for these values. So within these adapter classes, it would be useful to implement private extension methods to convert between the enums. – FlintZA May 09 '13 at 12:13
  • 1
    The limitation of extension methods being within a top-level class implies that the only static methods may only benefit from instance-style syntactic sugar are those which can and should be public (and as a consequence cannot use any private types). Perhaps the ability to declare such public methods was the driving motivation behind defining extension methods, but that doesn't imply public methods are the only useful scenario. Being able to have private-use-only extension methods use private types would be useful as well. – supercat Dec 06 '13 at 21:49
  • 1
    I think nested private static extension methods will have a very good use. Suppose you want to create a fluent style dsl for e.g. GetAnimals().SelectMammelsWithLegs(3).HaveEars().GetTheirNames() These methods return IQueryable where T can change after each extension method. But the points is these methods are applicable to just one class which is using these extension methods. So why should we create a public static class for extension methods which expose these methods to others when we don't want to. – adeel41 Mar 14 '14 at 14:30
  • 3
    Here's the nice example where I'd need this feature. Beacuse I'd like to make a fluent interface with extension methods and I'd like these extension methods to be available only within the given class. – dragan.stepanovic Jun 24 '15 at 21:04
5

As Eric Lippert has written many times in his blog, each change to C# is carefully evaluated against a set of criteria to justify it and not based on technology sake alone. In this case, what was not required to enable LINQ was cut off to reduce risk. Check this blog post from Eric for a similar question.

Pang
  • 9,564
  • 146
  • 81
  • 122
softveda
  • 10,858
  • 6
  • 42
  • 50
3

I believe that this was done so that compiler can locate/search the extension method in reasonable amount of time. Further, note that complier search extension methods only in set of namespaces that are in file scope - this is also done for similar reasons.

If you think about generic static class scenario, compiler must try to instantiate the concrete types for all possible type combinations in order to match the extension method. Even if complier can be smart in doing this, instantiating concrete type for calling extension methods may have side effect that developer may not be aware of.

VinayC
  • 47,395
  • 5
  • 59
  • 72
  • You could still have them be in scope whereever the class is, however. I.e, a nested static class's extensions would be in scope in the wrapping class; and in particular that's not problematic even if the wrapping class is non-static and generic. – Eamon Nerbonne Feb 04 '13 at 12:20
  • I've heard this argument (restriction of extension methods to non-nested, non-generic static classes to speed up their discovery) before, but am not so convinced anymore: I suspect it would be possible to very quickly identify all static methods in an assembly that are decorated with an `ExtensionAttribute`, namely by scanning the `CustomAttribute` CLI metadata table (see chapter II.22.10 of the [CLI specification (ECMA-335)](http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-335.pdf)). – stakx - no longer contributing May 08 '13 at 17:50