An array destructing specification choice

[Allen Wirfs-Brock]

On Nov 5, 2011, at 11:11 AM, Till Schneidereit wrote:

> On Sat, Nov 5, 2011 at 18:10, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>> 
>>> What if the RHS doesn't have a length property at all? Or it has one
>>> with a value that isn't convertible to a number? No need for that
>>> complexity.
>> 
>> This case is consistently handled throughtout the ES spec:
>>    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]


Alalen

>