Only Hermes compiler gives a correct warning for the unresolved LHS. Other engines still seem deviate from the PutValue in the spec: 'use strict'; undeclared = ( this.undeclared = 10, print(undeclared), 10 ); Should be a Ref.Error for LHS, while normally eval'ing RHS
-
-
Not a spec bug, it was spec'ed this way starting ES1 -- you have to maintain L-R order for simple assignment. Probably the spec can be relaxed though, with updating the LHS ref after evaluation of the RHS?
@awbjs? -
This devergence of browsers from the spec. has been discussed many times within TC39 and TC39 has always chosen to stand firm on the specification for this issues. (or at least, been unable to reach consensus to change the spec) cc/
@BrendanEich - 3 more replies
New conversation -
-
-
I'm confused. https://tc39.es/ecma262/#sec-assignment-operators-runtime-semantics-evaluation … 1.d.i evaluates the RHS before calling PutValue. After evaluating RHS, LHS will resolve and no reference error is thrown?
-
Nevermind. I see: It'll run HasBinding to create a reference which will be an UnresolvableReference; which then causes PutValue to throw in strict mode. Sounds like this should be changed... :)
End of conversation
New conversation -
-
-
It's already open as https://github.com/tc39/ecma262/issues/467 … (or an essentially equivalent issue, anyway). There's test262 tests which v8 xfails, too: https://github.com/v8/v8/blob/c79af35585567ad8ff68c3bdc6a90ca4a173e1cb/test/test262/test262.status#L33-L60 …
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
JavaScript, HTML, CSS, HTTP, performance, security, Bash, Unicode, i18n, macOS.