Kotlin destructuring more than five components

There are only 5 component functions defined for the List interface (as extension functions).

You can add your own component functions as extension functions:

operator fun <T> List<T>.component6() = this[5]
operator fun <T> List<T>.component7() = this[6]
// ...

This would work now:

val (a, b, c, d, e, f, g) = listOf(1, 2, 3, 4, 5, 6, 7)

From the docs:

And, of course, there can be component3() and component4() and so on.

Note that the componentN() functions need to be marked with the operator keyword to allow using them in a destructuring declaration.

Kotlin defines extension methods for these component destructors. Unlike data classes, these aren't generated infinitely with one for each item. It also makes them slightly dangerous, which I'll get back to later.

For reference, the definition is here, and the KDoc can be found here (search for component in the list. For easy access, here's component1).

As you can see in the source definition (and documentation for that matter, but the source makes it more visible), there are only 5 methods (component1 to component5), each of which call get(n - 1), where n is the ID of the component destructor.

If you want more, you'll have to define them yourself, in the pattern of:

inline operator fun <T> List<T>.componentN(): T {
    return get(N - 1)
}

(or in the style suggested in the other answer - they produce the same results.)

And again, where N is 6 and up, matching the amount of items you plan on having.

However, I wouldn't recommend this. It's much easier iterating over it with a for loop, and it's also less prone to error. Take for an instance this:

val (a, b, c, d, e) = listOf(1, 2, 3, 4)

That will throw an ArrayIndexOutOfBoundsException. If, however, you have a static list (and know what you're doing), destructing with componentN is safe. Although if you have a mostly static list where you want future flexibility, you can use a data class. Those also generate the componentN functions for you, and limit themselves to the amount of fields you actually have - which means no exceptions at runtime, but instead compiler errors.

If you use lists to enable iteration in addition to destruction, you can also take the alternative approach and define an operator fun iterator and return a list of the items.