What is the reason for not allowing named arguments for Java interop?

I have an Android project which calls old java code:

    ContactsListActivity.startForResultShare(
        this, STATE_MULTISHARE, -1, -1, R.string.global_title_send
    )

Far from ideal, I wonder why named arguments are not supported. If I write a small kotlin wrapper around the java call I get them:

// Small wrapper.
@Suppress("NOTHING_TO_INLINE")
inline fun startForResultShare(
    activity: Activity, @ContactsState typeOfContactList: Int,
    idChatUserPostToShare: Long, idChatToModify: Long, @StringRes title: Int
) {
    ContactsListActivity.startForResultShare(
        activity, typeOfContactList, idChatUserPostToShare, idChatToModify,
        title
    )
}

…
    // At call site.
    startForResultShare(
        activity = this, typeOfContactList = STATE_MULTISHARE,
        idChatUserPostToShare = -1, idChatToModify = -1,
        title = R.string.global_title_send
    )

In fact, I guess it would be possible to generate a …Kt.kt version of java files creating named arguments in the spirit of package-level functions when calling Kotlin from Java, at least for static methods, so I could directly write the following without the manual wrapper:

    ContactsListActivityKt.startForResultShare(
        activity = this, typeOfContactList = STATE_MULTISHARE,
        idChatUserPostToShare = -1, idChatToModify = -1,
        title = R.string.global_title_send
    )

Is this wrapping expensive, or does it have other problems I haven’t encountered yet?

2 Likes

Named arguments are not supported because storing argument names in .class files is an optional feature and is not enabled by default when compiling Java source files. The wrapping isn’t expensive; you’re able to do it because you have access to the Java source code and can retrieve the parameter names from there. In the general case, this information is not available.

1 Like

Are named arguments supported when the argument names are included in the .class files? If not, is there an open feature request to support this?

Thanks

2 Likes

Are there any new thoughts on this? I was thinking that maybe annotations in the Java sources could enable the feature selectively.

Use case: Gradle plugins written in Java (or Groovy, for that matter) could be used more clearly in Kotlin DSL Gradle scripts if named parameters were available.

That would make syntactic correctness of Kotlin code depend on the compiler arguments of a dependency. My gut says that that is probably too fragile for the Kotlin spirit. Relying on annotations in the Java sources is arguably not a lot more robust but at least the effect can be reproduced from Java sources alone.

1 Like