Interesting idea. I know your example shows a contract about the receiver param but I can imagine that kind of feature would also be applicable to tell the compiler the return type is the same as an arbitrary parameter’s type.
I wonder if there are any use cases for telling the compiler that the function returns exactly the same instance (as opposed to the same type) as a param. I can’t think of any uses off the top of my head but if they exist then it would be worth considering how that would interact with this contract suggestion.
Now that I think about it, I realize I was thinking of a different kind of behavior–I’m not sure how the Self-type cases would deal with a contract implementation since contracts are not inherited and would still require some way of referencing a self-type.
I would love to have self types, this would help a lot of dealing with extensible builders using interfaces and such. Especially when introducing “stages” of a builder, which depend on the builder type. So what is the problem of introducing it to Kotlin?
When a Manifold, a compiler plugin in Java for Java, achieve interop, why can’t Kotlin also?
“Using a Kotlin lib in Java” is like using a C++ lib in C or Ts in Js: You downgrade the language, you must live with the pain of missing features. You want that shiny new lib with great builder? Too bad, use Kotlin.
Alternatively you can add a compiler plugin for better integration, but then, what the point of using Java? Why not the most defining type? Recursive type? Or even Object?
I don’t care tbh, I just want this feature (tbf, I would kinda love some interop: recursive generics should do it). It has been 8 years already since this proposal came. Don’t wanna Java-speed feature release time. . _.
Just dew it, make it an experimental feature, take feedback and improve. A working example is better than many words in an 8-year-long thread.
Even python got it now: PEP 673 – Self Type | peps.python.org