Normative: new Annex B.3 clause to specify "AssignmentTargetType of LeftHandSideExpression : CallExpression" web reality.

[rwaldron]

The intention of this change is to allow JS engines which run in browsers to be spec conformant in their handling of assignment to CallExpression Arguments. Both Chrome and Firefox have attempted to make the following a Syntax Error:

f() = 1

...However they were unable to do so without breaking the web! As it turns out, every engine that runs in a web browser has implemented the same behavior:

$ eshost -x 'let f = () => {}; f() = 1'
#### ChakraCore

ReferenceError: Invalid left-hand side in assignment

#### JavaScriptCore

ReferenceError: Left side of assignment is not a reference.

#### SpiderMonkey

ReferenceError: cannot assign to function call

#### V8

ReferenceError: Invalid left-hand side in assignment

Note that non-browser embedded engines, which do not bear the same burden as the above engines, implement this according to the current specification:

$ eshost -x 'let f = () => {}; f() = 1' --no-color
#### engine262

SyntaxError: Invalid assignment target

#### graaljs

SyntaxError: Invalid left hand side for assignment

#### hermes

SyntaxError: invalid assignment left-hand side

#### Moddable XS

SyntaxError: no reference

#### qjs

SyntaxError: invalid assignment left-hand side

I'd like to propose that TC39 codify the web reality. If there is a better way to define this, please advise!

cc @syg @jorendorff

[bakkot]

See older discussion in #257.

Note that both SpiderMonkey and JavaScriptCore make this an early error in strict code, so it should be safe to make this legal only in non-strict code. V8 has use counters for this pattern in both strict and non-strict code, which show almost no usage in strict code and a nontrivial amount of usage in non-strict code.

[syg]

I agree with @bakkot in #2193 (comment). Seems like a good idea to clean this up for strict, but too risky for non-strict.

[devsnek]

Do we instead want to put non-strict in the main body with an "icky" note?

[rwaldron]

I've added the limitation to non-strict code, however I'm not sure the language is exactly right.

[ExE-Boss]

The Early Errors in https://tc39.es/ecma262/#sec-assignment-operators-static-semantics-early-errors also need to be modified by Annex B to allow CallExpression in sloppy mode.

[devsnek]

sending this again: Do we instead want to put this in the main body with an "icky" note?

[littledan]

Thanks for following up with this PR, @rwaldron . It's too bad we all dropped it on the floor earlier. LGTM in its current form.

Note that this version does not include logical assignment operators, and as such, V8 is banning this construct. (Apparently there are already test262 tests for this.) https://chromium-review.googlesource.com/c/v8/v8/+/2423721 . This prohibition seems appropriate to me, since it's not needed for compatibility.

[rkirsling]

Hmm, I always feel like it's better not to make an already-unfortunate rule more complicated than it has to be. We can certainly get away with allowing f() *= and banning f() &&= at parse time, but this requires awareness of &&= being a recent feature, in spite of the fact that it could have easily been added to the spec many years ago.

[bakkot]

this requires awareness

Awareness by whom?

[rkirsling]

Spec readers, I guess? I understand that users won't write this, and if they do they'll get an error sooner or later, but it seems odd to create two special rules when one will do—no one seems to benefit from the added complexity.