From [11.13.1 Destructuring Assignment]:
---
AssignmentProperty :
Identifier Initialiser{opt}
PropertyName : AssignmentElement
---
The optional `Initialiser` is most likely provided for consistency purposes, cf. `SingleNameBinding` [12.2.4 Destructuring Binding Patterns]. But since [11.1.5 Object Initialiser] does not contain any `PropertyDefinition -> Identifier Initialiser{opt}` production rule, an `Initialiser` can never occur in an `ObjectAssignmentPattern` and therefore the optional `Initialiser` should be removed from `AssignmentProperty`. That means the rule should look like:
---
AssignmentProperty :
Identifier
PropertyName : AssignmentElement
---
Note: This restriction does not apply to `AssignmentElement`.
We want consistency between Assignment destructuring and binding destructuring so we need to allow for an initialiser in both bases.
Rather than removing it from AssignmentProperty the fix is to add it to ObjectLiteral as a covering production. A static semantic restriction in PostfixExpression prevents this form from being used from regular object literals. It is in PostfixExpressiion because that is the lowers point in the expression grammar where we know we aren't on the lefthand-side of an assignment operator.
Fixed in Rev 10 editor's draft
I'm not sure whether adding a semantic restriction only to PostfixExpression helps, though. On the LHS of an AssignmentExpression could be a MemberExpression with a leading ObjectLiteral:
---
function f(){
({}.x = 0);
}
---
(In reply to comment #2)
> I'm not sure whether adding a semantic restriction only to PostfixExpression
> helps, though. On the LHS of an AssignmentExpression could be a
> MemberExpression with a leading ObjectLiteral:
> ---
> function f(){
> ({}.x = 0);
> }
> ---
You're right. I also need a few such restrictions on MemberExpression, CallExpression, and NewExpression.
An example of a case that would be of concern is ({x=1}.x = 0)
This is filtered out with restrictions on some of the
MemberExpression : MemberExpression . IdentifierName
production. The MemberExpression to the left of the . isn't allowed to derive an ObjectLiteral that contains an
PropertyDefinition : CoveredInitialisedIdentifier
production.
A semantic restriction on PostfixExpression (and MemberExpression, CallExpression, and NewExpression) won't help to resolve the additional issue reported at https://mail.mozilla.org/pipermail/es-discuss/2012-September/025124.html .
This could get really complicated. What about just removing the optional initializer from BindingProperty and AssignmentProperty when there is no ":"?
fixed in rev10, Sept. 27 2012 draft