An array destructing specification choice

Allen Wirfs-Brock allen at wirfs-brock.com
Sat Nov 5 11:13:17 PDT 2011


On Nov 5, 2011, at 10:57 AM, Claus Reinke wrote:

>> 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.

correct

> 
> If the rhs was an Array, ..

but it isn't

> 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'.

That's why I'm brought up the issue. The proposal doesn't say.  Figuring out edge cases like this is the job of your friendly specification writer (me...)

> 
> 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?-).

In general, JS, allows an object with integer property names to be used in any context where an "Array" is expect.  This seems like such a context.

> 
> Except.. 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'.

except, the LHS selectors are implicit so we can define the rules for determining them.  Also, we allow ... on the LHS and that also implies that something is going on besides simple sequential integer selector assignment. 

> 
> 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..).
> 

I favor consistency.  array-like objects should behave consistently in all contexts.  to me that says z should get the value undefined.


> 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 off?-)

I think that is pretty much what the proposed JS destructing really is.  I'm fine with calling it "destructuring"



> 
> Claus
> 



More information about the es-discuss mailing list