CODEWITHSUNDEEP
javascriptstandardsgrammar
Suma
Suma

Reputation: 34413

Why does JS computed property grammar allow assignment expression?

The Javascript grammar allows an assignment expression (AssignmentExpression) to be used in a computed property name (ComputedPropertyName) (see 12.2.6 Object Initializer or ES 2015 Grammarkdown):

ComputedPropertyName[Yield] :
    `[` AssignmentExpression[In, ?Yield]  `]`

This allows one writing e.g:

 var data;
 var a= {
          [data="something"]: "x"
        }

Why is this useful? Why is not enough having a ConditionalExpression instead? It seems as an unnecessary complication to the grammar.

Upvotes: 3

Views: 215

Answers (1)

rici
rici

Reputation: 241771

Basically, it is the reverse of your first thought. There is no need to special-case the kind of expression allowed inside a ComputedPropertyName, so the language designers chose to use the "normal" expression, which is an AssignmentExpression.

If you look through the EcmaScript grammar, you will see that the only place where ConditionalExpression is used is in the definition of AssignmentExpression. In this respect, it is similar to all the other expression sub-syntaxes defined in the grammar before AssignmentExpression, which are present only to define the operator-precedence order of the grammar. (A practical parser based on operator precedence parsing might not even have anything which corresponds to these various non-terminals.)

Basically, aside from defining operator precedence, there are only two expression non-terminals used in the grammar: AssignmentExpression and Expression. The difference has to do with the unfortunate C legacy of the comma operator (which evaluates and then forgets its first argument). Expression is used in contexts in which the comma operator is permitted:

Expression: AssignmentExpression
          | Expression ',' AssignmentExpression

including almost everywhere an expression is used in a Statement. AssignmentExpression (and no other Expression subsyntax) is used in contexts in which the , indicates a list of expressions: argument lists, array literals, and so on. It would have been very difficult to justify limiting the use of assignment expressions to just one obscure corner of the language, while they are usable in pretty well any other context which allows an expression.

There was actually an argument to make the ComputedPropertyName syntax even more permissive, rather than banning the use of the comma operator, since the property access syntax (MemberExpression '[' Expression ']') is one of the many places where the comma operator is permitted, although it is practically never used.

Actually writing array[i, j] is -- at least IMHO -- bad style, since it's almost certain to confuse naive readers who don't realise that it means the same thing as array[j] (unless evaluating i has a side-effect). In languages where the comma operator is available (C, C++, EcmaScript, and others), this usage is mostly an obfuscation technique, and StackOverflow contains lots of evidence that the obfuscation works. I'd like to think that only the need to maintain backwards compatibility with obfuscated code has prevented the Comittee from removing the comma operator from the property access syntax.

Since the ComputedPropertyName syntax is basically analogous to the property access syntax, one might have expected it to also be Expression, rather than AssignmentExpression. But apparently the Committee was able to resist the temptation.

Upvotes: 3

Related Questions