Why allow BindingPattern for BindingRestParameter

[saambarati]

I'm looking at this spec text:
https://tc39.github.io/proposal-object-rest-spread/#Rest
and
https://tc39.github.io/proposal-object-rest-spread/#Rest-RuntimeSemantics-RestBindingInitialization

Why not only allow an identifier for rest?

For example, I think this code is too difficult to understand (and has little real world value):

let {[a]: b, ...[c]} = expr;

What does this even do? Not what I would've expected it to.

I think I finally understand that it's something like this (with a lot of hand waiving):

let tmp1 = a.toString();
let b = expr[tmp1];
let tmp2= { ... expr - tmp1 properties }  ;
let [c] = tmp2;

[saambarati]

An example of JS that expresses why I think this is crazy:

Object.prototype[Symbol.iterator] = function() { console.log('foo'); return {next: function() { console.log('baz'); return {done:true}}}}
let {...[baz]} = {foo:20}

[saambarati]

An example of JS that expresses why I think this is crazy:

Object.prototype[Symbol.iterator] = function() { console.log('foo'); return {next: function() { console.log('baz'); return {done:true}}}}
let {...[baz]} = {foo:20}

[syg]

@anba has raised a similar point here: tc39/proposal-object-rest-spread#43

[syg]

@anba has raised a similar point here: tc39/proposal-object-rest-spread#43

[littledan]

Cc @gsathya @caiolima

[littledan]

Cc @gsathya @caiolima

[caiolima]

I don't think it's a good idea since we will not be consistent with Array Rest spec that allows recursively rest operations. IMHO it could bring confusion against intuitive usage of rest operations.

BTW, I think it's a good idea discuss this topic into tc39/proposal-object-rest-spread#43 since it is not part of spec yet.

[caiolima]

I don't think it's a good idea since we will not be consistent with Array Rest spec that allows recursively rest operations. IMHO it could bring confusion against intuitive usage of rest operations.

BTW, I think it's a good idea discuss this topic into tc39/proposal-object-rest-spread#43 since it is not part of spec yet.

[peey]

Do note the functional differences between let {...{a}} = expr and let {a} = expr

The first example would only set a only if a is expr's own property, but the second example is equivalent to a = expr.a.

Though it does get redundant after one level of nesting, I don't see much point in let {...{...{a}}} = expr

[peey]

Do note the functional differences between let {...{a}} = expr and let {a} = expr

The first example would only set a only if a is expr's own property, but the second example is equivalent to a = expr.a.

Though it does get redundant after one level of nesting, I don't see much point in let {...{...{a}}} = expr

[saambarati]

What do you mean by “only set a”? “a” will end up as not TDZ after both statements execute.

(FWIW, I understand there are other semantic differences in other ways to. Performing GetOwnPropertyNames is observable.)

Having a semantic difference isn’t a good enough reason to be in the language.

[saambarati]

What do you mean by “only set a”? “a” will end up as not TDZ after both statements execute.

(FWIW, I understand there are other semantic differences in other ways to. Performing GetOwnPropertyNames is observable.)

Having a semantic difference isn’t a good enough reason to be in the language.