Question

When it comes to extension methods class names seem to do nothing, but provide a grouping which is what name-spaces do. As soon as I include the namespace I get all the extension methods in the namespace. So my question comes down to this: Is there some value I can get from the extension methods being in the static class?

I realize it is a compiler requirement for them to be put into a static class, but it seems like from an organizational perspective it would be reasonable for it to be legal to allow extension methods to be defined in name-spaces without classes surrounding them. Rephrasing the above question another way: Is there any practical benefit or help in some scenario I get as a developer from having extension methods attached to the class vs. attached to the namespace?

I’m basically just looking to gain some intuition, confirmation, or insight – I suspect it’s may be that it was easiest to implement extension methods that way and wasn’t worth the time to allow extension methods to exist on their own in name-spaces.

Answer 1

Perhaps you will find a satisfactory answer in Eric Lippert’s blog post Why Doesn’t C# Implement “Top Level” Methods? (in turn prompted by SO question Why C# is not allowing non-member functions like C++), whence (my emphasis):

I am asked “why doesn’t C# implement feature X?” all the time. The
answer is always the same: because no one ever designed, specified,
implemented, tested, documented and shipped that feature. All six of
those things are necessary to make a feature happen. All of them cost
huge amounts of time, effort and money. Features are not cheap, and we
try very hard to make sure that we are only shipping those features
which give the best possible benefits to our users given our
constrained time, effort and money budgets.

I understand that such a general answer probably does not address the
specific question.

In this particular case, the clear user benefit was in the past not
large enough to justify the complications to the language which would
ensue. By restricting how different language entities nest inside each
other we (1) restrict legal programs to be in a common, easily
understood style, and (2) make it possible to define “identifier
lookup” rules which are comprehensible, specifiable, implementable,
testable and documentable.

By restricting method bodies to always be inside a struct or class, we make it easier to reason about the meaning of an unqualified
identifier used in an invocation context; such a thing is always an
invocable member of the current type (or a base type).