Out of curiosity I'd like to inquire about some potential language features Kotlin could have in principle. For each I would be interested if it is already in consideration (maybe with a link to an issue that I can track) or why it would not fit into Kotlin's design.
- Nimrod and D have the concept of Uniform Function Call Syntax. In Kotlin terms Nimrod and D thus have extension functions without the need to explicitly mark a function as an extension function like it is the case in Kotlin. A call `x.f(y)` is merely sugar for `f(x, y)`. Are there (technical) reasons to prefer explicit extension functions to UFCS for Kotlin?
- In Scala one can also define what are essentially extension functions with implicit classes. The advantage of Scala's approach is that the receiver has to be only written down once to define several extension functions at once. In Kotlin as it currently stands the receiver has to be repeated for each extension function even if they all have the same receiver. This increases Kotlin's “viscosity”. Is there something planned on that score?
- What about dynamic scoping like in Groovy or Scala? I think it would be a really nice addition having encountered a real use case in my code recently.
-
What about syntax sugar for the update method like in Scala? I actually see it kind of sceptical currently as I do not fully comprehend its limitations because I did not occupy myself with it much. For example, what happens with `x() += y`? Scratch that, I somehow forgot about Kotlin's index operation which is almost the same afaik. Although Scala's translation allows for an empty parameter list like `x() = y` which is translated to `x.update(y)`. Could Kotlin's index operation be relaxed this way to allow `x[] = y`?
- What about multi-methods a la Clojure, C# or Nimrod? Is their use case, like pattern matching, mostly beneficial for compiler writers to get rid of the Visitor Pattern?
- Nimrod and D have the concept of Uniform Function Call Syntax. In Kotlin terms Nimrod and D thus have extension functions without the need to explicitly mark a function as an extension function like it is the case in Kotlin. A call `x.f(y)` is merely sugar for `f(x, y)`. Are there (technical) reasons to prefer explicit extension functions to UFCS for Kotlin?
Being able to call (almost) any function as an extension means that there's no way of gathering meaningful code completion proposals fast. On top of that it's a lack of discipline, and we are planning to remove ambivalent syntactic opportunities from the language.
- In Scala one can also define what are essentially extension functions with implicit classes. The advantage of Scala's approach is that the receiver has to be only written down once to define several extension functions at once. In Kotlin as it currently stands the receiver has to be repeated for each extension function even if they all have the same receiver. This increases Kotlin's “viscosity”. Is there something planned on that score?
We may add some grouping for extension at some point, but not in the nearest future
- What about dynamic scoping like in Groovy or Scala? I think it would be a really nice addition having encountered a real use case in my code recently.
There are some Scala-like approaches we are considering, but no decision is taken yet.
- What about multi-methods a la Clojure, C# or Nimrod? Is their use case, like pattern matching, mostly beneficial for compiler writers to get rid of the Visitor Pattern?
Normal multi-methods are expensive to run and cumbersome to typecheck.
C#'s version is based on dynamic types. When we add those, we'll probably have something similar to C# as a side-effect: rather slow version of multi-methods with no static type-checking.
Thanks for the answers. The point about UFCS is as much as I assumed. Glad to hear that grouping of extension methods and dynamic scoping is considered and multi-methods will be possible. I vaguely remember the author of Nimrod talking about something like dispatch tables that are not vtables which would make the implementation of multi-methods much faster though I don't have anything concrete as to that.
any update on adding grouped extension updates?