https://kotlinlang.org logo
Join Slack
Powered by
The KEEP for name-based and new positional-based d...
# language-proposals
a
The KEEP for name-based and new positional-based destructuring is now open for public review https://github.com/Kotlin/KEEP/discussions/438
K 5
K 6
💯 1
z
Seems good. I'm curious though why parenthesis instead of curly brackets? Wouldn't it be more appropriate for brackets since they're typically associated with objects? example
Copy code
{ val a, val b } = Pair(1, 2)
In my opinion it's more natural I think Another thing what if the `val`/`var` could be lifted out the destructuring block if theyre all the same? Correct me if I'm wrong but immutable fields would be more common when destructuring. So it would be simpler to write for example
Copy code
val { a, b } = Pair(0, 1)
a
Brackets are not possible because they're already used to delimit blocks and lambdas. When the parser sees 
{ val x
, it cannot distinguish whether a new block is starting, or a destructuring is starting
about the second question, the KEEP defines a migration strategy to finally get to the usual 
val (a, b)
syntax (or 
val [a, b]
) we all know and love
a
what about
Copy code
val { val x, val b } = ...
val { x, b } = ...
👀
I'm about to send better explanation and example snippet as comment no need to go for 
()
when we can go with 
val {}
, which is familiar and repeatable in other contexts
a
I'll also reply in the KEEP, but 
{
is a no-go because it's not parseable
a
Looking back the discussion, I may have not phrased it clearly enough. In my response here, albeit brief, I said that my proposal can be adapted down to only destructuring:
Copy code
val { text } = f()
f().let { val { text } -> }
fun f2(val { text }: Foo) = ...
But I agree that my overall proposal talks about pattern matching, however, this is due to convey a bigger picture. To make my proposal non-matching, any fallible constructs can be removed and the idenfier at <obj> as well. --- Should I rewrite the proposal (separating patten deconstruction and matching) more clearly in KEEP format and post it in this channel?
I mean no harm, just to provide an alternative solution to the migration needs and overloading (which is... unfamiliar) the meaning of () from positional to nominal kodee frustrated
a
let me be maybe a bit more direct: the fact that there's no general matching, and that the syntax uses 
(
and not 
{
are concious decisions by the team. The feature is already there for a few version, on its way to stabilization, and migration help has been implemented in IntelliJ -- so honestly I don't think this decision is going to be reversed
a
Dang it, I came for it too late kodee frustrated
I thought that, due to it being experimental, it can be changed and the situation avoided. But apparently not.
a
due to it being experimental, it can be changed
In general, this is true. Context-sensitive resolution or companion blocks/extensions have changed their design during the review process. In this case, though, those issues were already raised during the design (both within our team and in the KEEP review), considered, and a decision was already made on those particular issues. This is why this case is different, and I don't expect reversing those decisions unless a very big issue arises.
a
Hmm, would've the design be different if I came earlier?
Also, isn't the migration a "very big issue" in itself, or due to the migration tooling the change is much easier to handle? Due to old code not being backwards compatible unless changed?
a
I don't think so: you're not the first one to raise those concerns and ideas
a
What were the reasons for staying with parens and going through a migration + having 2 distinct syntax variants, instead for opting into requiring `val`/`var` and choose something else?
In a different scenario, we would've had no migration, a single syntax variant, 
()
still meant componentN and positional (no need to even deprecate + still would've been familiar), 
[]
meant indexable (
get
) and 
{}
would meant nominal.
I'm a little bit frustrated, because I can't see an objective - not subjective - reason for why the decisions have been made that way. kodee floating This is why I'm asking you to reconsider (or at least briefly discuss) internally kodee loading , if it is really the path you would like to take for... the sunken cost of implementing the migration strategy 💀 .
a
this goes a bit with the idea of "better defaults", that is, we want the best option to also be the easiest option. In this case, that means re-purposing 
(
syntax to do name-based destructuring (which is the best default), and make position-based destructuring harder (because it doesn't work in the general case). It's not yet out, but I recommend watching Mikhail's talk at KotlinConf this year to get more background on this.
7 Views
Open in Slack
PreviousNext
Powered by