An array destructing specification choice

Brendan Eich brendan at mozilla.com
Tue Nov 8 07:40:09 PST 2011


On Nov 8, 2011, at 4:01 AM, Andreas Rossberg wrote:

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

Gotcha, my mistake -- thanks.


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

Agreed, you're right again. (I am 0 for 2!)


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

[yes, yes] does put more special casing and length-capturing-in-a-temp and bounds-checking, and that still makes me rebel against its consistency.

There's consistency in [no, no] too. Lasse's point that {0:x, 1:y} and [x, y] being the same is not a mark against consistency, but redundancy or lack of new semantics for the [x, y] pattern (viz, length filtering of the RHS properties). But that seems better to me on balance than the length sampling and bounding.


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

That's my thinking too.

We see people building such things with for-in loops in libraries today. That's a signal amid the noise.


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

Agreed. Thanks,

/be



More information about the es-discuss mailing list