1233767 - Support computed property names and defaults in destructuring declarations in for-in/of loop heads

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jeff Walden [:Waldo]]

js> for (var { [5]: x } in "foo");     
typein:2:11 SyntaxError: computed property names aren't supported in this destructuring declaration:
typein:2:11 for (var { [5]: x } in "foo");
typein:2:11 ...........^
js> for (var { [5]: x } of "foo"); 
typein:3:11 SyntaxError: computed property names aren't supported in this destructuring declaration:
typein:3:11 for (var { [5]: x } of "foo");
typein:3:11 ...........^
js> for (var { z: x = 3 } of "foo");
typein:5:14 SyntaxError: destructuring defaults aren't supported in this destructuring declaration:
typein:5:14 for (var { z: x = 3 } of "foo");
typein:5:14 ..............^
js> for (var { z: x = 3 } in "foo"); 
typein:6:14 SyntaxError: destructuring defaults aren't supported in this destructuring declaration:
typein:6:14 for (var { z: x = 3 } in "foo");
typein:6:14 ..............^

This will require somewhat special bytecode emission to deal with the per-loop iteration initialization/assignment of the variables.

Comment 1

[Mike Pennisi [:jugglinmike]]

This extends to destructuring assignment in for-in/of loop heads, as well
(although the error is not as clear):

    $ js -e 'for ({x = 0} of [{}]) {}'
    -e:1:10 SyntaxError: missing : after property id:
    -e:1:10 for ({x = 0} of [{}]) {}
    -e:1:10 ..........^

Comment 2

[Mike Pennisi [:jugglinmike]]

This bug also crops up in nested destructuring patterns (again with the more
generic error message):

    $ js -e '0,{ a: { b = 1 } } = { a:{} }'
    -e:1:13 SyntaxError: missing : after property id:
    -e:1:13 0,{ a: { b = 1 } } = { a:{} }
    -e:1:13 .............^

Comment 3

[Jeff Walden [:Waldo]]

I have a PR against the Github repo/branch where bug 1263355 is being worked on, that I believe fixes this.  Don't anybody bother testing it, tho, because there are known cases (e.g. any for-in/of loop with lexical declaration whose body captures one of those lexical declarations) where the PR falls down, because the underlying branch isn't fully completed yet.

https://github.com/syg/gecko-dev/pull/1

Comment 4

[Jeff Walden [:Waldo]]

Mike, comment 1 and comment 2 are separate issues, and definitely separate code is involved -- so not part of this bug.

At a super-fast skim of the code, and not really understanding the PossibleError things mrrrgn introduced semi-recently here except in a vague conceptual hand-wavy sense, I think comment 1 and comment 2 are a wholly-separate bug in how Parser::objectLiteral works.  Please file and needinfo her on it to look at it.

Comment 5

[Shu-yu Guo [:shu]]

This is almost fixed by bug 1263355, but shorthand default expressions in destructuring doesn't yet parse in for-heads:

for ({x=1} of [{}]) {}

still throws a SyntaxError.

Comment 6

[Tom S [:evilpie]]

(In reply to Shu-yu Guo [:shu] from comment #5)
> This is almost fixed by bug 1263355, but shorthand default expressions in
> destructuring doesn't yet parse in for-heads:
> 
> for ({x=1} of [{}]) {}
> 
> still throws a SyntaxError.

This works for me.

Comment 7

[André Bargull [:anba]]

bug 1305566 fixed the remaining parts here.

Comment 8

[Florian Scholz (Open Web Docs)]

I believe this is already documented.

Computed property names https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#Computed_object_property_names_and_destructuring

Default values https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#Default_values_2