Why do we need an explicit function interface modifier in Kotlin?

user_647129 0
Viewed 134

consider a SAM defined in Java

public interface Transform {
   public String apply(String str);
}

This interface supports lambda to type conversion in Kotlin automatically

fun run(transform: Transform) {
    println(transform.apply("world"))
}

run { x -> "Hello $x!!" } // runs fine without any issues

But now consider a Kotlin interface

interface Transform2 {

    fun apply(str: String): String

}

Now the only way to invoke the run function would be by creating an anonymous instance of Transform2

run(object : Transform2 {
        override fun transform(str: String): String = "hello $str!!"
})

but if we make the Transform2 interface a functional interface then the below is possible

run { str -> "hello $str!!" }

Why the Kotlin compiler cannot automatically type cast lambdas to matching interfaces (just as it does with Java interfaces) without needing to explicitly mark the said interfaces as a functional interface.

kotlin
2 Answers

I've found some kind of a rationale in a comment in KT-7770:

... treating all the applicable interfaces as SAM might be too unexpected/implicit: one having a SAM-applicable interface may not assume that it will be used for SAM-conversions. Thus, adding another method to the interface becomes more painful since it might require changing syntax on the call sites (e.g. transforming callable reference to object literal).

Because of it, current vision is adding some kind of modifier for interfaces that when being applied:

  • Adds a check that the interface is a valid SAM
  • Allows SAM-conversions on call sites for it

Something like this:

fun interface MyRunnable {
     fun run()
}

Basically, he is saying that if the SAM conversion were done implicitly by default, and I add some new methods to the interface, the SAM conversions would no longer be performed, and every place that used the conversion needs to be changed. The word "fun" is there to tell the compiler to check that the interface indeed has only one abstract method, and also to tell the call site that this is indeed a SAM interface, and they can expect the author to not suddenly add new abstract methods to the interface, suddenly breaking their code.

The thread goes on to discuss why can't the same argument can't be applied to Java, and the reason essentially boils down to "Java is not Kotlin".

user_51335850

This is speculation, but I strongly suspect one reason is to avoid encouraging the use of functional interfaces over Kotlin's more natural approach.

Functional interfaces are Java's solution to the problem of adding lambdas to the Java language in a way that involved the last change and risk, and the greatest compatibility with what had been best practice in the nearly 20 years that Java had existed without them: the use of anonymous classes implementing named interfaces. It needs umpteen different named interfaces such as Supplier, BiFunction, DoublePredicate… each with their own method and parameter names, each incompatible with all the others — and with all the other interfaces people have developed over the years. (For example, Java has a whole host of interfaces that are effectively one-parameter functions — Function, UnaryOperator, Consumer, Predicate, ActionListener, AWTEventListener… — but are all unrelated and incompatible.) And all this is to make up for the fact that Java doesn't have first-class functions.

Kotlin has first-class functions, which are a much more general, more elegant, and more powerful approach. (For example, you can write a lambda (or function, or function literal) taking a single parameter, and use it anywhere that you need a function taking a single parameter, without worrying about its exact interface. You don't have to choose between similar-looking interfaces, or write your own if there isn't one. And there are none of the hidden gotchas that occur when Java can't infer the correct interface type.) All the standard library uses function types, as does most other Kotlin code people write. And because they're so widely-used, they're widely supported: as part of the Kotlin ecosystem, everyone benefits.

So Kotlin supports functional interfaces mainly for compatibility with Java. Compared to first-class functions, they're basically a hack. A very ingenious and elegant hack, and arguably a necessary one given how important backward compatibility is to the Java platform — but a hack nonetheless. And so I suspect that JetBrains want to encourage people to use function types in preference to them where possible.

In Kotlin, you have to explicitly request features which improve Java compatibility but can lead to worse Kotlin code (such as @JvmStatic for static methods, or casting to java.lang.Object in order to call wait()/notify()). So it fits into the same pattern that you also have to explicitly request a functional interface (by using fun interface).

(See also my previous answer on the subject.)

user_101342090
Related