Kotlin 2.3.20 introduces an experimental feature that changes how destructuring declarations work: instead of relying on the position of properties in a data class, you can now unpack values by their field names. The feature is enabled with the compiler argument -Xname-based-destructuring=only-syntax and is expected to become stable in version 2.5.0 (end of 2026). By version 2.7.0 (end of 2027), the default behavior for destructuring with parentheses will switch from position-based to name-based.
What changes
Currently, destructuring in Kotlin is positional. Writing val (name, age) = person extracts the first and second components of person, regardless of what they are named. This works fine for simple cases but creates problems when you reorder properties, change a computed property into a primary one, or turn a class into an interface. The variable names you choose in the destructuring declaration have no connection to the actual property names.
The new syntax puts val inside the parentheses, one per property:
(val name, val age) = person
The order no longer matters. You can also rename properties on extraction:
(val age, val theName = name) = person
For cases where position-based destructuring still makes sense — pairs, triples, collections — the new syntax uses square brackets:
val [x, y] = point
// or
[val x, val y] = point
This syntax works everywhere destructuring is allowed: lambda expressions, loops, and let blocks.
Migration path
The compiler provides a migration helper under -Xname-based-destructuring=name-mismatch. When enabled, it warns about cases where position-based and name-based destructuring produce different results, or where code will stop compiling once the default changes. The IDE (IntelliJ IDEA) will offer quick-fixes, such as suggesting the new syntax or renaming variables.
You can already test the future default behavior with -Xname-based-destructuring=complete, but JetBrains warns that this can break existing code. The migration period is deliberately long: the feature is experimental in 2.3.20, stable in 2.5.0, and the default changes in 2.7.0. If the ecosystem is not ready by 2027, the change may be postponed.
Tradeoffs
Name-based destructuring solves real problems: it prevents accidental property swaps, simplifies refactoring, and works with interfaces and value classes without requiring manual componentN() functions. However, it introduces a new syntax that developers must learn, and it breaks existing code that relies on positional destructuring with mismatched variable names. The compiler will not deprecate componentN() functions for data classes — they will still be generated — but multi-field value classes will only support name-based destructuring.
When to use it
If you are starting a new project or have a small codebase, you can enable -Xname-based-destructuring=only-syntax now to get familiar with the new syntax. For larger projects, wait until the feature reaches stable status in 2.5.0, then use the migration helper to identify and fix problematic destructuring declarations. The long timeline gives you room to adapt without pressure.
Bottom line
Name-based destructuring is a significant change to Kotlin's syntax that improves safety and maintainability. The migration is well-planned, with tooling support and a multi-year transition period. Start experimenting now to avoid surprises when the default flips.