An array destructing specification choice

Till Schneidereit tschneidereit at gmail.com
Sat Nov 5 11:33:34 PDT 2011


On Sat, Nov 5, 2011 at 19:27, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>>>    ToInteger( obj.[[Get]]("length"))
>>> evaluates to 0 if length is missing or has a bogus value.
>>
>> So in your favored solution, would the following example result in x,
>> y, and z all being undefined?
>> let [x,y,z] = {0:0, 1:1, 2:2};
>
> yes
>
>>
>> It should, as no length is assumed to mean "length === 0", IIUC, and
>> that seems so unintuitive to me that it sways my opinion towards not
>> imposing array-ness on the RHS.
>
> but that is exactly how it works everywhere else length is used in ES.
>
>
>>
>> Thus:
>> let [x,y,z] = {0:0, 1:1, length:2, 2:2};
>> results in
>> x === 0, y === 1, z === 2;
>>
>> and
>> let [x,y,...r] = {0:0, 1:1, 2:2, length: 3, 3:3,4:4};
>> results in
>> x === 0, y === 1, r === [2, 3, 4];
>>
>> The last example hinges on the exact behavior of rest, of course. It
>> feels most natural to me to let it mean some thing along the lines of
>> "collect all not-yet destructured numeric properties into array 'r'".
>
> So you would be fine with the fact that
>
>   var r = Array.prototype.slice.call(0:0, 1:1, length: 2, 2:2}, 0);
>
> produces  [0,1]
>
> but
>
>  var [...rx] = {0:0, 1:1, length: 2, 2:2};
>
> produces [0,1,2]

Hmm, no. I agree with you that while your proposed destructuring
behavior in isolation seem unintuitive (my words, not yours, of
course), seen in full context of other functionality's behavior, it
would be more unintuitive for it to behave as I proposed.

It still seems pretty unfortunate to me not to be able to give this
intuitive, yet consistent with the rest of the spec, behavior.

> Alalen
>
>>
>
>


More information about the es-discuss mailing list