How about combining @fkowal’s syntax with @sideeffffect’s semantics / desugaring?
The syntax is just lovely. I think also you can’t be more to the point when you want define an Extension Method. An Extension Method “extends” a previously defined type, only that you “overwrite” that type with the “extended” version instead of defining a sub type. This “overwrite” is only in effect where the definition of that “extension” is in scope (so you control it—not like with Ruby’s Open Classes where such an “override” was global). Reusing the definition syntax of class types just feels most “natural” here.
(Mostly irrelevant fun fact: I arrived at more or less the same syntax thinking about that. I would, regarding syntax, go even one step further. I think you could leave out trait, class, maybe object, val, and def because the compiler can actually infer them, given some other ideas would get implemented. For sure class is not useful for anything anymore since we have Trait Parameters. I can explain the rest if someone wants to know, but that syntax change ideas are of topic here).
The issue with current Extension Methods: The current semantics under the hood, even with that new syntax, are quite complicated. “So it’s just an anonymous implicit class? What? You mean like a monoid in the category of endofunctors? Nobody understands that stuff…”
The idea that Extension Methods are in fact only a special case of function application is very interesting in my opinion. The idea is not novel, and has been implemented successfully already in a few languages. I see that as plus. “Stealing” good ideas makes them even more valuable! I think Rust is the most prominent example here, but I saw that feature on some Microsoft Research langs also (where the biggest a-ha moment was seeing something looking like JS, but then reading that it has no objects; I don’t remember how it was called). Such a desugaring of Extension Methods is easily understandable and its behavior hence predicable, even for beginners. It’s just a function application in the end, and one special rule. Compared with the overhead of an “implicit class” that’s an enormous win, imho. Especially on the axis of cognitive load when explain how it works, or thinking about the runtime details. From a more abstract viewpoint I like such a definition of Methods also because of its symmetry with functions. Methods are just functions with a self parameter! But one can hide this easily with some “extension block” syntax sugar (as proposed).