Assigning to globals in strict mode
Dmitry A. Soshnikov
dmitry.soshnikov at gmail.com
Mon Oct 18 09:03:49 PDT 2010
On 18.10.2010 19:59, Oliver Hunt wrote:
> On Oct 18, 2010, at 12:57 AM, Dmitry A. Soshnikov wrote:
>> On 18.10.2010 1:56, Oliver Hunt wrote:
>>> I'm just in the process of making jsc produce the correct error in strict mode when assigning to an undefined priority, and I just want to verify my understanding of the spec (which is somewhat confused by multiple people stating that in strict mode the assignment operator can never create a new global property).
>>> Per section 11.13.1 an implementation should throw a syntax error if LeftHandSideExpression evaluates to an unresolvable reference, which means
>>> "use strict"; undeclared = (this.undeclared = 5);
>>> Should throw as |undeclared| will not exist when LeftHandSideExpression is evaluated.
>> As far as I can see, yeah, it's a ReferenceError. However, it will be more logical not to have it (because of grouping operator which logically assumes precedence). The situation can be corrected if to exchange first and the second steps of the 11.13.1.
>>> "use strict"; this.declared = 5; declared = (delete declared, 5);
>>> Will not throw, but instead will recreate the |declared| property.
>> Following 8.7.2, it will also throw because of step 3. However, this case (in contrast with the previous with assignment) looks more logical, 'cause grouping operator assumes that this action should be made first. That is, we have first deleting of the `declared`, and then trying to assign 5 to undeclared `declared`.
>> So to make the first case more logical, I propose to change 1st and 2nd steps of the 11.13.1:
>> 1. Let rref be the result of evaluating AssignmentExpression.
>> 2. Let lref be the result of evaluating LeftHandSideExpression.
>> and to add a small note, clarifying for what it is needed.
> Swapping the evaluation of left and right side of an assignment expression would be a fairly bad change -- you're effectively breaking the left to right evaluation of expressions present in every other part of ES :-/
Yeah, fair enough, didn't think about it. The evaluation order (which is
here for years) has higher priority than this "confusing" case.
> It certainly would not be a backwards compatible change (I recall there being website regressions when we were originally bringing up the bytecode interpreter in squirrelfish due to us having incorrect evaluation order of assignments.
> Alas short of a double resolve I'm not sure that the idea of "assignment never creates a global" can be specified. That said I think the current model prevents the typical scenario that led to accidental construction of a global.
More information about the es5-discuss