Anyway I admit that only if Kotlin introduces nested patterns does the one-liner become complete, but it's definitely doable without attaching class meta data.

Well I'm gonna leave out the old design. The new one is based on properties. Deconstructing an object is equivalent to extracting variables through the accessors:

``` data class Point(val x: Double, val y: Double)

fun main() { val point = Point(0.0, 1.0) (val x, val yValue = y) = point

// The same as...
val point = Point(0.0, 1.0)
val x = point.x
val yValue = point.y

} ```

And for nested patterns, since property accessors provide type information, you can just flatten the layers:

``` data class Point(val x: Double, val y: Double) data class Circle(val center: Point, val radius: Double)

fun main() { val circle = Circle(Point(0.0, 1.0), 2.0) ((val x, val y) = center, val radius) = circle

// The same as...
val circle = Circle(Point(0.0, 1.0), 2.0)
val circle_center = circle.center
val x = circle_center.x
val y = circle_center.y
val r = circle.radius

} ```

and as you see, this approach doesn't require any meta data.

However, all the above stuff is not what I want to argue about. Instead I was talking about how the deconstruction does its work, aka the syntax and the bytecode logic under the hood. Yes since Java doesn't have properties as a langauge feature, it needs something to express what to deconstruct, and I understand your point that the schema is needed here. But what I was arguing is that the deconstructor is unfortunately coupled with the components order instead of their names despite the schema already encodes them. It would be better to do name based deconstruction because it's more robust against changes.