@zdenko Can you please merge2 into thedestructuring_object branch and resolve conflicts? I took a crack at it, but there are a lot of conflicts to resolve. Basically thedestructuring branch in#4478 overlapped with much of what you were doing. You branch started from my original destructuring approach, which wasn’t nearly as clean or robust as@connec’s, so for#4478 we abandoned mine in favor of his; and his got merged into2. So now you need to work backwards a bit and start from this new starting point, where object destructuring is already implemented in2, and you only need to add the object spread destructuring. The2 branch also already has destructured objects in function parameters.

If it’s easier to start a new branch that branches off of2, and then cherry-picks some work from thedesctructuring_object branch, that works too. I can change the branch that this PR pulls from. Please put the new branch on my repo, though, so the rest of us can contribute. Thanks!

Multiple rest elements are disallowed.

What about when merging objects like this?

letobj={a:1,b:2,c:3,d:4}letoverride={b:'b',d:'d'}constmerged={...obj, ...override}

Whichworks with thestage-3 preset in babel…

@connec was that last commit it? Does this now have your blessing?

@lydell and@zdenko, do either of you want to final pass at this, or can I merge it in?

OK, that's definitely me done now@GeoffreyBooth. My last concern was the grammar, which didn't account for things like{super()...} or{this...}. There might still be some missing cases since using anything broader likeValue orExpression leads to ambiguity (as I'm sure@zdenko can testify).

I didn't add tests for those things, and it's really late here now. Other than that, I think this is good to go (of course, as a contributor to the PR I now can't be trusted to be impartial 😄).

At this point I’d rather merge it in and handle additional edge cases as further PRs. This has become an epic.

Last call!

So I was writing the documentation for this, and the example I came up with doesn’t compile:

user=name:'Werner Heisenberg'occupation:'theoretical physicist'currentUser=  user...status:'Uncertain'

[stdin]:6:6: error: unexpected ...user...    ^^^

However changingcurrentUser tocurrentUser = { user..., status: 'Uncertain' } makes it work as expected. A similar example using arrays works as expected. Is this a bug?

@GeoffreyBooth this works

currentUser = {  user...  status: 'Uncertain'}

I've tried to make it work without the{} in the past but always ended with ambiguity issues.

Okay, well at least it just throws a compiler error for now. So if we figure out how to support that syntax later, we can add it in a later PR.

That's probably related tolookObjectish in the rewriter, which seems to only accept implicit object literals when there's a: involved (which is consistent with being unable to use shorthand properties in implicit objects.

Tbh we probably want to leave it like this, or we'll need to face down ambiguities in expressions like

fk: v, rest...

Which, currently, will compile to two arguments (an object literal and a splat param) but would be ambiguous if we allowed splats to exist in implicit objects.