Assigning to globals in strict mode

Oliver Hunt oliver at apple.com
Mon Oct 18 08:59:22 PDT 2010


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.
> 
>> Similarly
>> 
>> "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 :-/

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.

> Dmitry.

--Oliver



More information about the es5-discuss mailing list