Shouldn't `ComputedPropertyName` use `Expression` and not `AssignmentExpression`?

[dead-claudia]

I suspect this is a spec oversight, hence why I'm filing this as a bug.

• https://tc39.es/ecma262/#prod-ComputedPropertyName: [ AssignmentExpression[+In, ?Yield, ?Await] ]
• https://tc39.es/ecma262/#prod-MemberExpression: MemberExpression[?Yield, ?Await] [ Expression[+In, ?Yield, ?Await] ]
• https://tc39.es/ecma262/#prod-SuperProperty: super [ Expression[+In, ?Yield, ?Await] ]
• https://tc39.es/ecma262/#prod-CallExpression: CallExpression[?Yield, ?Await] [ Expression[+In, ?Yield, ?Await] ]
• https://tc39.es/ecma262/#prod-OptionalChain: ?. [ Expression[+In, ?Yield, ?Await] ]

One of those is not like the others, and it's generated some confusion over in the ES Discourse. Considering you can't even destructure anything at that location in parameters, it feels like a spec oversight in ES2015 that's been there ever since.

[bakkot]

I think the unfortunate thing is that computed property access allows comma expressions, but that of course can't change. So I strongly suspect this was not an oversight, but rather a deliberate decision not to propagate this unfortunate fact to new syntax.

[theScottyJam]

I think the unfortunate thing is that computed property access allows comma expressions

Why so?

I think it's unfortunate the comma operator exists in the first place, but given that it exists, why should it not be allowed in computed property access?

[bakkot]

Because [a, b] looks a whole lot like an array.