An array destructing specification choice

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Nov 11 22:39:58 PST 2011


On Nov 11, 2011, at 5:06 PM, David Herman wrote:

> On Nov 11, 2011, at 3:36 PM, Allen Wirfs-Brock wrote:
> 
>> ...
>> We currently haven't specified this syntactic form.  I'm not sure if it adds enough value to justify the added conceptual complexity.
> 
> I think it's a pretty big win, and I'd argue it's totally intuitive. The great thing about destructuring is that you can intuit the semantics without actually having to understand the details of the desugaring/semantics.
> 
> Also: we'll definitely want to allow it for splicing, so the grammar will have to allow it already, and symmetry/consistency argue for allowing it in destructuring too. Likewise for function formals and actuals.

Embedded spreads is already in the ES6 draft for  both array literals and argument lists.  I'm not at all sure that embedded rests in destructurings are such a good idea.  Just to start with, what does this mean:

   [a,b,...r,c,d = [1,2,3]

Similarly for formal parameters:

  (function (a,b,...r,c,d) {return [a,b,c,d]})(1,2,3);

If it isn't obvious what it means it probably should be in the language.

I believe implementers will generally want positional parameters to be a fixed stack offsets so constant offsets can be emitted into the instruction stream for referencing them.  Allowing the above, means that the offset of c and d need to be dynamically determined for each invocation.  

This sort of destructuring is not real pattern matching. Non-righthand side trailing rests seem like it is pushing things too.  It goes beyond reasonable utility and comprehensibility into something whose semantics is non-obvious and which may negatively impact implementations. 

Allen






More information about the es-discuss mailing list