add @static support for extension method

[He-Pin]

Dotty now has extension method support : https://dotty.epfl.ch/docs/reference/contextual/extension-methods.html
and Dotty is adding @static support too, can we add static support for extension method so we can add factory like methods to the origin type.
Dart has an issue for this too:dart-lang/language#723

[liufengyun]

To clarify, currently in Dotty, @static definitions have to be located in the companion object of a class. During compilation, it will be moved to the companion class. Therefore, strictly speaking, @static does not change semantics of the surface language nor make it more expressive.

[LPTK]

@hepin1989 you can already achieve what you want, without using @static, by simply making the extension on the singleton type of the companion object (for instance List.type).

[Jasper-M]

Is @static still considered experimental, unfinished, unsupported? It doesn't seem to appear in the reference docs either.

[He-Pin]

@LPTK What if the type is defined in Java?

[liufengyun]

Is @static still considered experimental, unfinished, unsupported? It doesn't seem to appear in the reference docs either.

It's completed but not documented, it's going to be part of Scala 3.

[LPTK]

@LPTK What if the type is defined in Java?

@hepin1989 hmm... then I guess you're out of luck. But that's quite a niche use case, and I'm not sure it warrants special support.

[smarter]

It's completed

In my opinion it isn't, for example if I write:

object Test {
  @static val foo: Int =
    List(1,2,3).reduce(_ + _)
}

The generated code does contain a static field foo in class Test, but the body of this field ends up calling a lambda defined in Test$, thereby forcing Test$ and negating the whole point of @static. I'm sure there's more issues like this, and it would require a lot of time and effort to really determine wha this annotation should do in all cases, so I'm still for removing it.

[liufengyun]

I'm sure there's more issues like this, and it would require a lot of time and effort to really determine wha this annotation should do in all cases, so I'm still for removing it.

I missed the context when @static was introduced initially. My current understanding is that the main reason to use @static is for Java 2 inter-operability. This will be important for Scala projects that target both Scala and Java users. It's pretty common for big-data related projects.

[He-Pin]

refs :Kotlin/KEEP#347

[SethTisue]

some recent discussion at https://contributors.scala-lang.org/t/scala-3-extension-method-for-object-and-java-class/6135

[Jasper-M]

Re extension methods for java "companion objects":

I think this could fairly easily be made to work once you have erased definitions. The problem is that String is not a real companion object so it cannot be passed around as a value, but you can define an extension method like this:

extension (erased a: String.type) def hello = "I am String"

Now you should be able to call String.hello since the “value” String is erased at runtime. Unfortunately in the latest snapshot release you get the error

value hello is not a member of object String

Could even be made more ergonomic if the compiler would define all java “companion objects” as instances of erased classes. Then you as a user don’t need to think about adding erased or not.

In a way java companion objects have always been "erased". So would be cool to build that on top of first class erased support.