<p>C# 3.0 introduced extension methods to &quot;enhance&quot; 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 <code>this</code> (so that it makes extension methods null-safe in terms of calling a method on &quot;this&quot;, but obviously static methods obey visibility rules).</p>
<p>So are Kotlin extensions (have never worked with Kotlin, but Kotlin declarations look more natural to me though).</p>
<p>In Java there is no such thing as extension methods (Java 8+ interface default methods are not merely syntax sugar), however <code>javac</code> plugins like Lombok or Manifold allow using extension methods right in Java.</p>
<p>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.</p>
<p><s>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 (<code>staticMethod(obj)</code> -&gt; <code>obj.staticMethod()</code>, or whatever non-dot like <code>obj.:staticMethod()</code>)? What implications might this idea have?</s></p>
<p>I've just came across <a href="https://langdev.stackexchange.com/questions/265/advantages-of-extension-methods-vs-uniform-function-call-syntax-ufcs">this question</a> 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?</p>
<p><sub>My question does not seem to be a duplicate of <a href="https://langdev.stackexchange.com/questions/1961/what-are-the-advantages-and-disadvantages-of-extension-methods">this question</a>.</sub></p>

<syntax><java><extension-methods><c#>
What if all static methods in Java or C# could be extension methods just by default?
CC BY-SA 4.0
2023-11-30T15:15:05.513Z
Extension methods relate to the **Expression Problem** (https://en.wikipedia.org/wiki/Expression_problem), which is "how do we provide a way for third-party code to extend a datatype's *representation* (i.e. add subclasses) and *behaviors* (i.e. add methods)?" Object-oriented languages like Java and C# allow you to extend a third-party class's representation, and extension methods *partly* allow you to extend behaviors.
tarzh
CC BY-SA 4.0
2023-11-30T15:15:12.550Z
But they don't count as a solution, because extension methods can't be virtual. The fundamental issue is if one third-party codebase were to define a virtual extension method, and a completely separate library defines a new subclass, the new subclass won't have an implementation for the new extension method.
tarzh
CC BY-SA 4.0
2023-11-30T19:42:44.583Z
What kind of consequences of having all static methods eligible to be used as extension methods are you interested in? Are you asking about the backwards compatibility problems it would create?
Eldritch Conundrum
CC BY-SA 4.0
2023-11-30T22:42:02.350Z
@EldritchConundrum Yes, mostly backwards compatibility issues and drawbacks it might bring up (e.g., importing all classes from a package in Java would probably add too much static=extension methods this way). As of now, to me, it looks like syntax sugar that breaks nothing (I still don't know). I think that the C# designers might consider this approach too, but they chose a slightly weird syntax to declare extension methods. If I get the UFCS concept right, the D and Nim designers thought over it and adopted it (did the concept appear in the initial version of the languages or later?)
terrorrussia-keeps-killing
<p>Disclaimer: this answer is based the underlying concepts and nomenclature from C#.</p>
<p>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.</p>
<p>If every static method becomes eligible for use in the extension-method syntax, then name clashes will happen. So:</p>
<ul>
<li>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.</li>
<li>You might try to do the name resolution by declaration, e.g. with an extension of the &quot;using&quot; syntax. But that would not fit into the current semantics of &quot;using&quot;, that it's completely optional, that, by always writing fully-qualified names, there is no need for &quot;using&quot;. If you don't want to break that, you'd still need the &quot;fully qualified method name&quot; call-syntax extension.</li>
</ul>
<p>In C#, it's required to mark the static methods by</p>
<ul>
<li>residing in a static class</li>
<li>and using the <code>this</code> keyword with the first parameter.</li>
</ul>
<p>Typically, there are so few candidates for the name clashes that the problem can be ignored.</p>
<p>My personal opinion is that the syntax sugar called &quot;extension methods&quot; 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.</p>
<p>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 <a href="https://lisp-lang.org/learn/clos" rel="nofollow noreferrer">CLOS</a> as an example for such an approach.</p>

CC BY-SA 4.0
2023-12-01T08:32:49.847Z
2023-12-01T08:32:49.847Z
Ralf Kleberhoff
CC BY-SA 4.0
2023-12-02T10:33:36.240Z
Thank you for the answer! Yes, I also realized that the same method names and signatures in different classes would be ambiguous hence requiring a sort of declaration class qualifier at the call site. This really makes the idea of "extensions by default" weak to me. Extending the `using` keyword seems pretty much like the `javac` Lombok plugin does: the class that uses "extension" methods must be annotated where to import the extension methods from (once per a class, but I'm not sure the scope the current and the extended versions of the `using` keyword).
terrorrussia-keeps-killing
CC BY-SA 4.0
2023-12-02T10:41:58.163Z
This also led me to an idea that C# made a good choice by not making static methods extensions, especially because a compilation unit in C# imports a whole namespace rather than import-cherry-picking like what Java does -- otherwise this really would probably bring ambiguity issues. The only thing about C# extension methods declaration syntax I'm wondering about is why the C# designers adopted the first argument syntax in the form of `(this Type p1[, ...])` rather than a bit more concise and probably "more natural" `(Type this[, ...])` (the latter wouldn't seem to break the grammar, I guess).
terrorrussia-keeps-killing
CC BY-SA 4.0
2023-12-11T13:10:00.957Z
My question has gained low interest over days. Thank you for your time!
terrorrussia-keeps-killing
CC BY-SA 4.0
2024-01-10T05:12:12.040Z
@terrorrussia-keeps-killing I have no recollection of why we chose `this T` over `T this`, but I was not yet regularly attending design meetings when that feature was designed. I'll check my notes!
Eric Lippert
CC BY-SA 4.0
2024-01-10T07:23:55.180Z
@terrorrussia-keeps-killing: This point was debated and coincidentally it was exactly 19 years ago this week. "T this" was rejected because you would have to change the name of the parameter if the static method already existed and was made an extension, and it makes the code less self-documenting.  That then left the question of how to signal intention to make an extension method.
Eric Lippert
CC BY-SA 4.0
2024-01-10T07:29:27.960Z
@terrorrussia-keeps-killing The rejected options considered were `public static extension RETURNTYPE NAME(PARAMLIST)` , and `[Extension] public static ...`, and adding `as this` after the parameter name and that sort of thing. Language design isn't about finding the perfect, it's about making reasonable compromises that feel right.
Eric Lippert
CC BY-SA 4.0
2024-01-10T07:32:11.890Z
@terrorrussia-keeps-killing: To address your earlier point, yes there was also a vigorous debate over whether there should be a mechanism for cherry picking particular static classes, and there were ambiguity-avoidance arguments made on both sides.
Eric Lippert
CC BY-SA 4.0
2024-01-10T08:36:49.200Z
@EricLippert Wow, it's a real honor to have my low-interest question commented by a core design team member! This question bugged me for about 15 years (especially since I switched to the Java/JVM stack and I really missed a similar mechanism in the Java language), and it's very nice that you spent your time to share the notes that are 19 years old very this week. What a sign! Thank you!
terrorrussia-keeps-killing
# What if all static methods in Java or C# could be extension methods just by default?
Posted by: username_0 on 2023-11-30
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](https://langdev.stackexchange.com/questions/265/advantages-of-extension-methods-vs-uniform-function-call-syntax-ufcs) 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](https://langdev.stackexchange.com/questions/1961/what-are-the-advantages-and-disadvantages-of-extension-methods).
**Tags:** syntax java extension-methods c#
> **Comments:**
> **username_1**: Extension methods relate to the **Expression Problem** (https://en.wikipedia.org/wiki/Expression_problem), which is "how do we provide a way for third-party code to extend a datatype's *representation* (i.e. add subclasses) and *behaviors* (i.e. add methods)?" Object-oriented languages like Java and C# allow you to extend a third-party class's representation, and extension methods *partly* allow you to extend behaviors.  
> **username_1**: But they don't count as a solution, because extension methods can't be virtual. The fundamental issue is if one third-party codebase were to define a virtual extension method, and a completely separate library defines a new subclass, the new subclass won't have an implementation for the new extension method.  
> **username_2**: What kind of consequences of having all static methods eligible to be used as extension methods are you interested in? Are you asking about the backwards compatibility problems it would create?  
> **username_0**: @EldritchConundrum Yes, mostly backwards compatibility issues and drawbacks it might bring up (e.g., importing all classes from a package in Java would probably add too much static=extension methods this way). As of now, to me, it looks like syntax sugar that breaks nothing (I still don't know). I think that the C# designers might consider this approach too, but they chose a slightly weird syntax to declare extension methods. If I get the UFCS concept right, the D and Nim designers thought over it and adopted it (did the concept appear in the initial version of the languages or later?)  
---
## 1 answers
### Answer by username_3 on 2023-12-01. Score: 3 | Accepted answer
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](https://lisp-lang.org/learn/clos) as an example for such an approach.
> **Comments:**
> **username_0** (2023-12-02): Thank you for the answer! Yes, I also realized that the same method names and signatures in different classes would be ambiguous hence requiring a sort of declaration class qualifier at the call site. This really makes the idea of "extensions by default" weak to me. Extending the `using` keyword seems pretty much like the `javac` Lombok plugin does: the class that uses "extension" methods must be annotated where to import the extension methods from (once per a class, but I'm not sure the scope the current and the extended versions of the `using` keyword).  
> **username_0** (2023-12-02): This also led me to an idea that C# made a good choice by not making static methods extensions, especially because a compilation unit in C# imports a whole namespace rather than import-cherry-picking like what Java does -- otherwise this really would probably bring ambiguity issues. The only thing about C# extension methods declaration syntax I'm wondering about is why the C# designers adopted the first argument syntax in the form of `(this Type p1[, ...])` rather than a bit more concise and probably "more natural" `(Type this[, ...])` (the latter wouldn't seem to break the grammar, I guess).  
> **username_0** (2023-12-11): My question has gained low interest over days. Thank you for your time!  
> **username_4** (2024-01-10): @terrorrussia-keeps-killing I have no recollection of why we chose `this T` over `T this`, but I was not yet regularly attending design meetings when that feature was designed. I'll check my notes!  
> **username_4** (2024-01-10): @terrorrussia-keeps-killing: This point was debated and coincidentally it was exactly 19 years ago this week. "T this" was rejected because you would have to change the name of the parameter if the static method already existed and was made an extension, and it makes the code less self-documenting.  That then left the question of how to signal intention to make an extension method.  
> **username_4** (2024-01-10): @terrorrussia-keeps-killing The rejected options considered were `public static extension RETURNTYPE NAME(PARAMLIST)` , and `[Extension] public static ...`, and adding `as this` after the parameter name and that sort of thing. Language design isn't about finding the perfect, it's about making reasonable compromises that feel right.  
> **username_4** (2024-01-10): @terrorrussia-keeps-killing: To address your earlier point, yes there was also a vigorous debate over whether there should be a mechanism for cherry picking particular static classes, and there were ambiguity-avoidance arguments made on both sides.  
> **username_0** (2024-01-10): @EricLippert Wow, it's a real honor to have my low-interest question commented by a core design team member! This question bugged me for about 15 years (especially since I switched to the Java/JVM stack and I really missed a similar mechanism in the Java language), and it's very nice that you spent your time to share the notes that are 19 years old very this week. What a sign! Thank you!  
---
