An array destructing specification choice

Andreas Rossberg rossberg at
Tue Nov 8 04:01:51 PST 2011

On 7 November 2011 22:46, Brendan Eich <brendan at> wrote:
> On Nov 7, 2011, at 3:04 AM, Andreas Rossberg wrote:
>> One possible semantics could be treating
>>  let [x, y, z, ...r] = e
>> as equivalent to
>>  let {0: x, 1: y, 2: z, ..._r} = e
>>  let r = [], 3)
>> where I assume the "canonical" matching semantics for object rest
>> patterns that would make _r an ordinary object (not an array)
>> accumulating all properties of e not explicitly matched (even if e
>> itself is an array, in which case _r includes a copy of e's length
>> property). Of course, engines would optimize properly.
> Right, but why the 3 passed to if _r captured all enumerable properties except those with ids 0, 1, and 2 (stringified, of course)?

I was assuming that we want

  let [x, y,z,  ...r] = [1, 2, 3, 4, 5]

to bind r to [4, 5]. For that to hold, you have to shift down the
numeric indices in _r by 3, which is what the slice call was intended
to do.

At least that's the behaviour I'd expect from an array rest pattern,
and Allen's earlier example in this thread seems consistent with this
assumption. But looking at the proposal, I now see that it does not
actually do the shifting. So now I'm confused about what the intended
semantics actually is.

> Anyway, you've hit what I was advocating over the weekend as the answer to the pair of questions I posed: [no, no]. Lasse makes a good case for [yes, yes].

The call to .slice implicitly reads the length, so it rather seems to
implement [no, yes].

Using [no, no] would work, too, but requires a somewhat non-standard
form of slicing. I have a slight preference for being consistent with
the existing slicing semantics.

I don't like [yes, yes] that much. I prefer to view array patterns
merely as straightforward sugar for object matching, and [yes, yes]
kind of breaks that and puts more special cases into the language. So
I'd actually turn around Lasse's argument. :)

> I still think we should argue about row capture in object patterns a bit before concluding. What do you think?

Well, I think that row capture in object patterns is indeed a useful
feature, esp for record-like use cases. I agree that shallow cloning
isn't a big problem -- in any case, it's no worse than doing the same
sort of cloning for array-like objects.

It also seems more consistent to me to have rest patterns in both
forms. If object rows enable maintaining the "syntactic sugar"
explanation for array patterns, then the overall result might even be
a slightly simpler language.


More information about the es-discuss mailing list