This is really preliminary, but I thought I’d create this PR just to start the conversation. I could use a lot of help with this. 😬@zdenko has done some great work with object destructuring; I would love if you could also help tackle the core of ES destructuring!

I didn’t want to commit any code that horribly breaks the tests, so all I’ve committed so far are various helpers that I think will be necessary in order to getAssign to produce destructured output at least for the simplest case,{a} = b.

So I can get that case to output correctly, as:

varb;({ b}=a);

if I changenodes.coffee:1773-1782 to the following:

acc=idx.unwrap()instanceof PropertyNamevalue=newValue valuevalue.properties.pushnewIndex idxunless accmessage=isUnassignableobj.unwrap().valueobj.error messageif messagevalue=newOp'??', value, defaultValueif defaultValueassignOptions=param:@paramwrapVariableInBraces: accreturnnewAssign(obj, value,null, assignOptions).compileToFragments o, LEVEL_TOP

but doing that causes 6 tests to fail, and those tests verge on incomprehensible to me.

I’d like to start small and gradually expand to more and more complicated destructuring cases, but it appears that destructuring is implemented in a very compact, recursive way that discourages piecemeal approaches. Perhaps@lydell you can help untangle it? I’m hoping to avoid the near-rewrite that I did for the function parameters. At least function parameters are a straightforward concept that I’m pretty sure I understand; destructuring can get awfully complicated . . .

Okay, I’ve made a lot of progress. The tests now pass, and simple cases like{a} = b now output in ES syntax. Any feedback on the approach so far?

Update: The branch I started this PR with has been renameddestructuring-geoffrey and@connec’s branch that he submitted#4479 with has becomemy repo’sdestructuring, and therefore the source for this PR.

So picking up from#4479, I think@connec’s approach for destructuring is more promising than the one I was pursuing, so I want to start from his branch and cherry-pick improvements from mine. Top on my list is default values.@connec did you have an implementation in mind for those? How do you feel aboutthe way default values are implemented in my branch, and does that complement your approach?

Copied from#4479 -

I'll take another look tonight.

The main approach I'm going for is to use as much of the existing machinery as possible. If you look at the nodes for destructured expressions they look like they should just about compile verbatim, and it's only guard logic innodes.coffee that's preventing that. With some small tweaks we should be able to update the guard logic to be more permissive (e.g.here).

For compiling default values, I was planning to just leverage the existing node structure, e.g.

$echo'{ a = 1 }'| bin/coffee -bnsBlock  Assign    Value      Obj        Assign          Value IdentifierLiteral: a          Value NumberLiteral: 1    Value IdentifierLiteral: b

We should be able to tweakObj so that it will compile that inner assign verbatim, rather than doing special handling forAssign's whose context isn'tobject.

By destructured parameters I just mean e.g.({a}) ->, which on my branch compiles to

(function(arg){vara({a}=arg);});

...but could be compiled to

(function({a}){});

Again, I suspect there's some small logic tweak we could make to the parameter handling to make them compile more things in-line.

I've merged@connec's branch into mine and made some progress with the rest element in object destructuring. I'll try to fnish a.s.a.p and push changes.

It seems to be working fine, and currently, this:

obj={a:1,b:2,c:3,d:4,e:5}{a,b:z,d,r...}=obj

compiles to:

vara,d,obj,z,r;obj={a:1,b:2,c:3,d:4,e:5};({    a,b:z,    d}=obj),r=Object.keys(obj).reduce((a,c)=>(!['a','b','d'].includes(c)&&(a[c]=obj[c]),a),{});

Nice work! I feel like destructuring is finally coming along.

One note: should your generated output be using=>? I know it's common style in ES, but a coffee lint rule that I tend to follow says not to use the bound/fat arrow unless you need it, i.e. unless you're usingthis inside the function.

@GeoffreyBooth I've updatedmy branch with compilation of default values. The implementation was fairly smooth. I don't seem to be able to push it here, however (no permissions?).

@connec did you try to push it to GeoffreyBooth:coffeescript/destructuring? You're a collaborator there, you should be able to push. This PR is based on that branch on my repo.

Ah yes, it was my bad - I had your remote set as HTTPS but my authentication is SSH. I've updated the branch!

@lydell are you okay with these revisions?

I’d like to get this merged in and tackleGeoffreyBooth#4 on its own.

Could you post two examples where we fall back to the old code generation, and what they compile to? One for objects and one for arrays. Just want to think how they differ, and if they are a potential gotcha. Otherwise LGTM.

Sure. As far as I can tell the old code is only being used for splats and expansions, and for function parameters after splats or expansions:

// [x,y...,z] = [a,b,c,d,e]vari,ref,x,y,z,slice=[].slice;ref=[a,b,c,d,e],x=ref[0],y=3<=ref.length ?slice.call(ref,1,i=ref.length-1) :(i=1,[]),z=ref[i++];// f = (a, b..., {c}) ->varf,slice=[].slice;f=function(a, ...b){varc,i,ref;ref=b,b=2<=ref.length ?slice.call(ref,0,i=ref.length-1) :(i=0,[]),({c}=ref[i++]);};

UntilGeoffreyBooth#4 lands there are no splats or expansions within objects, so I guess we’re not using the old code at all for any object destructuring.

I guess the gotcha is destructuring generators, then?

$ node> g = function *(){yield 1; yield 2; yield 2}[Function: g]> [a, ...r]=g(){}> a1> r[ 2, 2 ]

I'm thinking that[a, r...] = g() would pull values out of the generator, while[a, r..., b] = g() wouldn't? If so, I'm not sure what to do about it other than docs?

That isn’t really a fault of this PR, as there’s no destructuring there; but it’s something we should consider. Basically “non-final” function parameters fall back to the legacy compilation, which involves caching the result of a function call, e.g.:

// [a, r…, b] = g()vara,b,i,r,ref,slice=[].slice;ref=g(),a=ref[0],r=3<=ref.length ?slice.call(ref,1,i=ref.length-1) :(i=1,[]),b=ref[i++];

Because of theref = g(),g only gets called once here. In your example, I guess…r callsg untilg is exhausted? What ifg could generate infinitely?

I guess the “solution” would be to once again restrict ourselves to ES semantics, and only allow splats in the final parameter. But I don’t want to do that for such a fringe edge case as this . . . I guess a note in the docs, yeah.

Anyway, leaving function parameters aside, how’s the destructuring? 😄

In your example, I guess...r callsg untilg is exhausted? What ifg could generate infinitely?

g is called exactly once.g()returns a generator....r does take the next value of until the generator is exhausted. If the generator is infinite, you simply end up in an infinite loop. Note that other than using array destructuring, you can also use the.next() method on generators to pull values out of them.

I'm not really sure I understood the rest of your comment, but I think we're good to go on this PR.

I’m not really sure I understood the rest of your comment

I just mean that splats as the final parameter compile nicely into ES:

// (a, b, c...) ->(function(a,b, ...c){});

But splats in any non-final position aren’t supported in ES, and so we need to do some shenanigans:

// (a, b..., c) ->varslice=[].slice;(function(a, ...b){varc,i,ref;ref=b,b=2<=ref.length ?slice.call(ref,0,i=ref.length-1) :(i=0,[]),c=ref[i++];});

And these shenanigans aren’t equivalent to ES in the case of handling generators, as you’ve pointed out. I’m not sure there’s a wayto make them equivalent without a runtime check that the assignment target is a generator function as opposed to a regular function. This maybe deserves an issue of its own, even if we decide it’s too fringe of an edge case to address.

You guys are really cooking on this — bravo!

And these shenanigans aren’t equivalent to ES in the case of handling generators

Will that not actually work fine? Generator unpacking only happens at the call-site anyway, so these all work identically to ES2015 equivalents:

g=->yield ifor iin [1..3]returnf= (a,b...,c)->return [a, b..., c]console.logfg()# [g, undefined]console.logfg()...# [1, 2, 3]console.logf0,g()...,4# [0, 1, 2, 3, 4]

@GeoffreyBooth I just ran into something that broke (I assume unintentionally) as a result of this pull request: eg({a: {b = 1}}) -> compiled ok before this PR but giveserror: unexpected = after. This destructuring also breaks in a destructured assignment:{a: {b = 1}} = c also giveserror: unexpected =