<https://twitter.com/kotlin/status/127608345685494...

# announcements

[user]

https://twitter.com/kotlin/status/1276083456854941697
Avoid using destructuring declarations together with non-trivial custom data classes: it will be too easy to break your code if you add new properties to such classes later. #KotlinTips https://t.co/yzjQXTVbdm
Twitter

[diesieben07]

Just a sign that we need name-base destructuring! 😄

[vaskir]

...or don't use primitive types for anything.

[diesieben07]

How does that help?

[vaskir]

city is decomposed to be passed somewhere I guess, so, the place where it's passed accepts city: String, this is the problem. If it accepted city: City, the code won't compile after Address being decomposed to ..., city: PostalCode.

[diesieben07]

That only shifts the problem one level downwards. What's City then? Probably data class City(val name: String).
And:
val (name) = city
But now a city also needs a nickname:
data class City(val nickName: String, val name: String)
Tada, its broken again

[diesieben07]

You can then of course say "`name` should not be of type `String`", but then the same happens again

[vaskir]

well, I didn't know Kotlin's deconstruction syntax so broken 🙂

[diesieben07]

It's purely position-based. That was my point 😉

[vaskir]

that's ok, but allowing deconstructing 3-fields class to two variables is a very strange behavior.

[vaskir]

I've not seen such feature in any language.

[diesieben07]

data class Complex(val real: Double, val imag: Double)
val (imag, real) = someComplex

Will not do what you want. The omitting of values is not the problem.

[sindrenm]

I would love name-based deconstruction as well. But what would the API for setting up for deconstruction look in that case? Currently we have fun componentN (where N is the position of the field we're pulling out). Having such a system allows for setting up deconstruction logic ourselves. Of course, when the compiler deals with it for us (as is the case for data classes, for instance), then it doesn't matter, but those other cases are interesting.

[diesieben07]

Bikeshedding: operator fun componentName() would destructure to name. The compiler would generate that for data classes of course

[diesieben07]

Or why not allow destructuring any accessible property? As in val (name, age) = person is sugar for val name = person.name; val age = person.age

[pavi2410]

Has anyone filed a feature request for it yet? I'd love to see this coming 😍

[diesieben07]

https://youtrack.jetbrains.com/issue/KT-19627