https://kotlinlang.org logo
Join SlackCommunities
Powered by
I'm curious, if there has ever been a proposal for...
# language-proposals
n
I'm curious, if there has ever been a proposal for, or interest in, "named" destructuring Kotlin has your typical destructuring that's also seen in a number of other languages. it's positionally based:
Copy code
data class foo(val i: Int, val s: String)
val (s, i) = foo(5, "hello")  // Reverse order you might expect, s is an int, i is a string
One could imagine doing it by name of the field instead. Imagine we use =, to piggy back off of the analogy between positional and named arguments
Copy code
val (=s, =i) = foo(5, "hello")  // okay, now it matches by name instead, so we create a variable s that's a string, i that's an int
It would require that there was a property with the name of the variable. if not, compiler error. behind the scenes it just gets translated to:
Copy code
val unusable = foo(5, "hello")
val s = unusable.s
val i = unusable.i
Advantages would be that it would allow destructuring "safely", without worrying about getting the order right. It's a relatively minor/simple thing to implement, easy to understand at first glance, and has a similar benefit for correctness as named arguments over positional arguments.
👍 2
e
personally I hope for named component destructuring in https://github.com/Kotlin/KEEP/pull/213
but in the meanwhile,
Copy code
with(foo(5, "hello")) {
    // i: Int
    // s: String
}
n
Sure, with only works well with one object though really
And you have to nest
But yeah full blown pattern matching is a way to go
Usually I find this means you have to repeat the type though, as in Rust
e
Named component destruction in high on our wish-list, but so far we were unable to come with a nice Kotliny syntax for it. Using 
=
is an interesting idea that I, personally, have not seen before. Thanks for throwing it in.
Note, though, that given all the other features Kotlin already has (like 
with
and other scope functions), Kotlin (unlike some other languages) is not in a dire need to have this feature.
They key problem with this proposal (and many other JS-inspired ones) is that it is not tooling-friendly. When you start typing 
val (=
there’s no way IDE can know which class you are trying to destructure and what names should be suggested in auto-completion. This conflicts the whole Kotlin philosophy of being a tooling-friendly language.
n
@elizarov thanks for your response! Yeah, I see your point about tooling. However, the same thing applies to the current destructuring
the problem with 
with
is, IMHO, a problem that I notice frequently in Kotlin.
The language is incredibly convenient, and expressive, when working with one object. When you have to work with multiple objects simultaneously, you immediately feel a step more awkward.
with
works great when you have a single object and you want to work with some variables from it with shorter names. If you have two objects and you want to pull some members from both, it does not work very well
maybe extending 
with
to take multiple arguments, but that has the downside that you silently override parameter names as you work inwards
actually I'm not sure if with can be extended in that way, I don't know what the type of the received lambda would be
e
The current destructuring is positional for a reason. It designed for things like Map.Entry and Pair whose component names are irrelevant, but position is everything. You should not use them with classes that have meaningfully-named components. Yes, we don’t have a concise syntax to pull a few named components from them into your scope, but we cannot steal this trick from JS either.
We have idea on how to make 
with
with multiple things to work, but it does not solve the problem of cherry-picking components.
n
yes, that is true
there is at least overlap, use case wise though
a way to make 
with
work for multiple things would be huge, btw, assuming it's something more general
there are a lot of other examples of multi object use cases
use
, locking multiple mutexes in a designated order, etc
e
Yes, it is more general. Stay tuned.
n
👍
s
Looking forward to this one. One of my favourite features of js
n
I'm a little late to the chat, but named destructuring is high on the wishlist too for keep 213 (pattern matching )
n
@Nico i could be wrong but my understanding is that in pattern matching you'd need to name the type
it would be more like 
foo(s, i) = ...
at least, haskell and rust pattern matching both look like this in this use case
n
That's naming the pattern ('as-pattern' in Haskell iirc) which is different and is not part of the proposal (given smart casting, it seemed a bit redundant). I really meant destructuring by property name instead of by position
n
ah, ok, good to know
should read it more carefully then
5 Views
Open in Slack
PreviousNext
Powered by