What if all static methods in Java or C# could be extension methods just by default?

Question

C# 3.0 introduced extension methods to "enhance" behavior of existing types without interface bloating to avoid modifying/breaking existing interfaces. This was the first time I learned of such a concept. If I'm not mistaken after 15 years of not working with C#, extension methods are just static methods with their first parameters marked with this (so that it makes extension methods null-safe in terms of calling a method on "this", but obviously static methods obey visibility rules).

So are Kotlin extensions (have never worked with Kotlin, but Kotlin declarations look more natural to me though).

In Java there is no such thing as extension methods (Java 8+ interface default methods are not merely syntax sugar), however javac plugins like Lombok or Manifold allow using extension methods right in Java.

C#, Kotlin, and the Manifold plugin uses the declaration-site approach: the extension method declarations must declare they can be used as extension methods (Manifold, if I remember well, allows declare a whole class of extension methods at once). Lombok uses a call-site approach: the class using extension methods can inject all static methods from specific classes, as if all the injected methods were declared extension methods.

I'm wondering, if all of these implementations use static methods, how would it affect if any scope-visible static methods could be merely used as extension methods not requiring extensions to be declared at declaration-site or call-site at all (staticMethod(obj) -> obj.staticMethod(), or whatever non-dot like obj.:staticMethod())? What implications might this idea have?

I've just came across this question and the idea above seems to be equal to UFCS, so let me rephrase the question above: how would it affect Java and C# that both have mature codebases?

_{My question does not seem to be a duplicate of this question.}

Answer 1

Disclaimer: this answer is based the underlying concepts and nomenclature from C#.

If you make every static method callable like an extension method, one problem becomes prominent that, in the restricted concept of C#, rarely shows up.

If every static method becomes eligible for use in the extension-method syntax, then name clashes will happen. So:

• You either need a method-call syntax that explicitly names the method to be called, including the name of the static class where the method resides. But then these calls look very different from normal method calls.
• You might try to do the name resolution by declaration, e.g. with an extension of the "using" syntax. But that would not fit into the current semantics of "using", that it's completely optional, that, by always writing fully-qualified names, there is no need for "using". If you don't want to break that, you'd still need the "fully qualified method name" call-syntax extension.

In C#, it's required to mark the static methods by

• residing in a static class
• and using the this keyword with the first parameter.

Typically, there are so few candidates for the name clashes that the problem can be ignored.

My personal opinion is that the syntax sugar called "extension methods" is rather poisonous. The static method that gets called behaves very differently from methods inside the class (is not polymorphic, accepts null, has no access to class internals, ...). So, making both types of call look similar hurts language clarity, IMHO.

If you want the ability to add methods to pre-existing classes, your language should completely throw away the idea that methods are part of a class. Maybe you want to have a look at LISP's object-oriented concept CLOS as an example for such an approach.