An array destructing specification choice

Brendan Eich brendan at
Mon Nov 7 13:36:17 PST 2011

On Nov 7, 2011, at 12:59 AM, Lasse Reichstein wrote:

> If the object being destructured is in fact a plain Array, with no
> inherited elements above the length, then there is no difference.
> This is most likely the (very) common use case. This is what the ES
> programmers' intuition will be based one.


> The original question was what an ES programmer would expect.
> I think he will probably expect array-like deconstructors to treat the
> RHS as an array(-like object).
> I.e., [yes,yes].

js> a = [0,1]
[0, 1]
js> Array.prototype[2] = 2
js> a.length
js> a[2]

We do not filter Array [[Get]] of an index that happens to name an inherited property based on length.

This still doesn't mean a whole lot, as you say. It's the very uncommon case. But it makes that with inherited indexed properties, length is not always overriding.

> That also have the advantage of actually providing otherwise
> unavailable functionality.
> You can write {0:x, 1:y, 2:z} instead of [x,y,z] if you want
> object-behavior, but if they are the same, you can't get array-like
> behavior.

This is a good point. Allen made it too, IIRC.

> Arrays are just an abstraction in ECMAScript, which all the
> Array.prototype methods that are "intentionally generic" proves. If it
> quacks like an Array and swims like an Array, we allow ourselves to
> treat it like an Array.

See above for a meow from the array-with-inherited-indexed-properties-not-below-length duck. But that's an edge case, I agree.

> I.e., I think the most easily comprehensible behavior is to make array
> destructuring treat the RHS as an Array.
> It matches the common use-case (actual arrays), it is consistent (does
> the same whether you use ... or not), and is easily explainable.

The destructuring becomes a bit more complicated, with a temporary for rhs.length and a one-time up-front "get" of that property, and lhs positional index tests against that length temporary. Still bugs me, probably as an implementor but also just in terms of more complicated desugaring.


More information about the es-discuss mailing list