An array destructing specification choice

Claus Reinke claus.reinke at
Sat Nov 5 10:57:30 PDT 2011

> In the following declaration, what should be the value of z?
> let [z,y,z] = {0:0, 1:1, length: 2, 2:2};

and there I was, thinking I understood more than half of JS..

Since this was new to me, I referred to the spec. Here 
<strike>is my reading</strike> are my readings:

The rhs is an Object, but not an Array - in spite of duck typing, 
the spec's isArray and Object initializer seem clear on this.

If the rhs was an Array, ..
object literal instantiation appears to be defined as going from 
left to right, so the '2:2' would increment 'length'. I haven't 
checked the destructuring proposal, but suspect if this was 
valid, the second match for 'z' would just overwrite the first,
leading to 'z' being '2'.

However, ..
since the rhs isn't an Array, but the lhs matches Arrays, I 
would (now) expect this to fail (where is real pattern 
matching with fall-through when you need it?-).

destructuring isn't even structural matching, it is just a 
concise description of object/array selectors. And array 
selectors are just object selectors, no checks for isArray. 
So the rhs isn't an Array, but the lhs isn't one, either, we 
just get a sequence of selections, and 'z' will be '2'.

This is way too confusing to be nice, or expected.  If the 
spec hard-codes the just-selectors-no-matching intuition, 
this version of the spec will have fewer surprises, but yet 
another syntax will be needed when moving to refutable 
matching in later versions.. 

perhaps that's not too bad (except for the fact that I'd 
like to separate objects and arrays more clearly..).

So, do we have to rename 'destructuring' to 'selector
shorthand', with the braces and brackets only defining
selection-by-name vs selection-by-index? Or am I way 


More information about the es-discuss mailing list