Let’s split this into two issues:
- The immediate tactical issue that we need a fix for. We are polluting our codebase with lots of methods that exist for no other reason that to keep the JVM linker happy, this is the sort of thing in a compiler’s domain. We can tolerate not being able to re-order named parameters for now, we have an ABI checker tool that will catch it if someone tries. So just generating more synthetic methods will help. This is the proposed PR.
- The longer term issue. I’d rather not solve this by introducing new annotations or language features … the goal should be to eliminate complexity and obscure requirements on developers, not just make them more visible. It feels to me like the “right” fix for this is to experiment with lifting Kotlin method linkage out of the JVM and into the Kotlin stdlib using invokedynamic, the linker code in the stdlib can then handle all the cases where binary and source linkage don’t match. For instance it can detect that a method would fail to link because of named parameter ordering changes, and then use reflection data to patch things up so the program can proceed. It can handle the case where a parameter type becomes a supertype, thus breaking binary linkage but not source linkage, and patch that up too. And so on and so forth. This is a more sophisticated and invasive change, but it doesn’t have to be too invasive, and making it much easier to build backwards compatible software can only have a positive effect on the whole Kotlin/JVM ecosystem.
But for now I’d be happy with a fix for (1). I’m still waiting for feedback on the tactical compiler-level fix from JetBrains. If we get the go-ahead I’ll schedule it into my team’s backlog to tackle.