This article was inspired by the one from Jaewoong Eum, that describes how to exclude irrelevant class imports from auto-complete suggestions.

I was once designing a public API for a library product that needed to be convenient for both Kotlin and Java clients. If you write in Kotlin, you may know that for data classes the compiler generates lots of stuff for us, including componentN() functions for destructuring primary constructor parameters.

Destructuring is a Kotlin language feature that allows you to assign multiple variables at once from a single source. Say, if you have val pair = Pair("value1", 42), you can then call val (a, b) = pair. It’s possible when a class has operator functions component1(), component2(), etc., no matter if they’re its own or extensions.

So, these auto-generated functions in data classes are rather implicit, and if you work with a data class in Kotlin, everything looks ok:

But that’s how it looks from Java:

But that’s how it looks from Java:

<completion.contributor
        language="JAVA"
        implementationClass="your.package.KotlinDataClassCompletionContributor"/>

...
<depends>org.jetbrains.kotlin</depends>
<depends>com.intellij.modules.java</depends>

Now let’s get to the core – implementing the CompletionContributor. You can review the full source code here, it’s relatively concise and straightforward. I’ll focus on the most interesting part – how to actually find generated operator functions componentN() to filter them out.

And now the plot twist… They are neither operators nor functions.

Let’s consider, say, the following data class:

data class User(val firstName: String, val lastName: String) {
    operator fun component3() = "$firstName $lastName"
}

And test it with our implementation. Let’s take the beginning of the shouldFilterOut function and add the log right after:

val psiElement = lookupElement.psiElement as? KtLightMethod ?: return false
val ktOrigin = psiElement.kotlinOrigin ?: return false
println("psiName = ${psiElement.name}; originName = ${ktOrigin.name}; $ktOrigin")

What we’ve done here:

• filtered PSI Elements that are a KtLightMethod. It’s a type that represents Kotlin functions and properties in a way Java can understand, that is useful for code analysis, refactoring, and auto-completion purposes
• filtered those which have the original Kotlin PSI element

Then we see something interesting in the logs:

psiName = component3; originName = component3; FUN
psiName = getFirstName; originName = firstName; VALUE_PARAMETER
psiName = getLastName; originName = lastName; VALUE_PARAMETER
psiName = component1; originName = firstName; VALUE_PARAMETER
psiName = component2; originName = lastName; VALUE_PARAMETER

Interestingly, both getters, as well as component1() and component2() functions, are represented in the PSI as VALUE_PARAMETER, despite being callable as functions in Kotlin. This representation suggests that these elements are directly tied to the constructor parameters.

Now, here’s an important note: despite what we see in the PSI, these auto-generated componentN() functions are still technically functions in Kotlin. It’s just that the PSI represents them differently, making them look more like parameters than functions.

However, you may note that our explicit component3()representation is different from the ones of the auto-generated componentN() functions. Moreover, they’d still be different even if it was operator fun component3() = firstName, i.e. pointed right to a value parameter.

And that’s good news for us! When you call the User class from Kotlin, the explicit componentN() function is not being filtered out:

...
val isParamInDataClass = ktOrigin.containingClass()?.isData() == true && ktOrigin is KtParameter
if (!isParamInDataClass)
    return false
return componentNRegex.matches(psiElement.name)