skip to content

How do you skip a component you don't need in a destructuring declaration, and what does the `_` placeholder actually do?

level: juniorimportance: should knowfreq 55%

answer

  1. `_` skips a position
  2. Skipped component's componentN() is NOT called
  3. Works in declarations, for-loops, lambdas
  4. No implicit trailing skip — write a `_` per slot
  5. Avoids unused-variable warnings

basics

~10 s

Put an underscore _ in the position you want to ignore: val (_, y) = point. Kotlin then skips that value and doesn't create a variable for it.

solid answer

~40 s

Use the underscore placeholder `_` to skip a component you don't need: `val (_, second) = pair`. When the compiler sees `_`, it does NOT generate a `val` for that slot and, importantly, does NOT call the corresponding `componentN()` function at all — so a skipped component's side-effects don't run. You can skip leading, middle, or any positions, and use multiple underscores: `val (_, _, third) = triple`. The same works in `for` loops and lambda parameters: `for ((_, value) in map)`. This keeps you from declaring unused variables that would otherwise trigger warnings, and clarifies intent. You cannot use `_` to skip trailing components implicitly — you still write a `_` for each position before the last one you want.

code

kotlin · 8 lines
kotlin
data class Row(val id: Int, val name: String, val age: Int)

fun main() {
    val (_, name, _) = Row(1, "Ada", 36)
    println(name) // Ada
    val map = mapOf("a" to 1)
    for ((_, v) in map) println(v) // 1, key ignored
}

go deeper

for a junior

Knows _ ignores a position and avoids the unused-variable warning.

for a middle

Explains it works across declarations, loops, and lambdas, with no implicit trailing skip.

for a senior

Knows _ suppresses the componentN() call, which matters for component functions with side-effects.

for a principal

Frames _ as intent-documenting and cautions against component functions with side-effects in the first place.

## The skip placeholder Kotlin lets you ignore positions you don't need with the underscore `_`: ```kotlin data class Triple3(val a: Int, val b: Int, val c: Int) val (a, _, c) = Triple3(1, 2, 3) // b is skipped ``` Here `a = 1`, `c = 3`, and no variable is created for position 2. ## It actually omits the call Unlike naming an unused variable, `_` makes the compiler **not call** the corresponding `componentN()`. So if `component2()` had a side-effect, it would NOT execute. This matters only for hand-written component functions that do work; for plain data-class fields it is a pure read either way. ## Where it works - Declarations: `val (_, y) = point` - Loops: `for ((_, value) in map) { use(value) }` — skip the key - Lambda parameters: `list.map { (_, b) -> b }` ## Multiple and any-position skips You can skip several or any positions: ```kotlin val (_, _, third) = someTriple // ignore first two val (first, _, _) = someTriple // ignore last two ``` There is no implicit trailing skip: to reach the 3rd component you must write placeholders for positions 1 and 2. ## Why use it - Avoids the "variable never used" warning. - Documents intent: "I deliberately ignore this slot." - Prevents unnecessary `componentN()` invocations. `_` here is the same lexical token used to ignore lambda parameters and (since they're conventions) is purely a compiler instruction — there is no runtime placeholder object.

  • Does using `_` still call the corresponding componentN() function?
    No. The compiler omits the call entirely for a `_` slot, so any side-effects in that component function are skipped.
  • Can you skip trailing components without writing underscores?
    No. You must include a `_` for every position before the last one you actually bind.

Like telling a delivery to 'leave slot 2 empty' — the courier never even opens that compartment.

saying these in an interview costs you the question

  • Claiming `_` creates a real variable named underscore
  • Saying componentN() still runs for skipped slots
  • Thinking you can omit trailing positions implicitly
  • Believing `_` only works in lambdas, not val declarations

context