- 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
is merely sugar for
. 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.