An array destructing specification choice

[Brendan Eich]

On Nov 7, 2011, at 3:04 AM, Andreas Rossberg wrote:

> On 5 November 2011 19:55, Brendan Eich <brendan at mozilla.com> wrote:
>> On Nov 5, 2011, at 9:38 AM, Allen Wirfs-Brock wrote:
>> 
>>> In a similar vain, what is the value of r in:
>>> 
>>> let [z,y,...r] = {0:0, 1:1, 2:2, length: 3, 3:3,4:4};
>>> 
>>> should it be [2] or [2,3,4]  (and if the latter how is that determined)?
>> 
>> The inspiration for ... in the past came from (among other sources) Successor ML:
>> 
>> http://successor-ml.org/index.php?title=Functional_record_extension_and_row_capture
> 
> Since I actually wrote half of that, I feel obliged to say that it
> does not answer the questions raised here. ML is a typed language, and
> contrary to popular belief, many language design problems are much
> easier to solve in a typed setting.

Absolutely. Remember, we sought inspiration there back in ES4 days, with optional types of some sort hovering (and eventually flying away, presumably to Denmark ;-).


> However, there is some inspiration in the way SML treats tuples as
> special cases of records, very much like arrays are a special case of
> objects in JS. In particular, all of SML's pattern matching rules for
> tuples follow just from the way they desugar into records with numeric
> labels.

Yes, this was our thinking for destructuring, which first appeard in Opera, got some ES4 wiki-level spec drafting, and fed into the SpiderMonkey and Rhino implementations.


> 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 = [].slice.call(_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 slice.call if _r captured all enumerable properties except those with ids 0, 1, and 2 (stringified, of course)?

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]. I still think we should argue about row capture in object patterns a bit before concluding. What do you think?


> (But yes, row capture for objects introduces a form of object cloning,
> as Allen points out.)

Shallow, though. No closure cloning, e.g. Clone as curse-word shouldn't shoot this down without specific argument.

/be