Transitioning to strict mode

Mark S. Miller erights at
Thu Feb 21 12:50:00 PST 2013

I think I would have preferred that. But thinking back to the constraints
we imposed on ourselves during the ES5 design process, I doubt we could
have made that choice. Every additional difference between ES3 (or ES5
sloppy) vs ES5 strict had to be argued for. The counter-argument was
"migration tax". Given how slow the uptake of strict mode has been, the
migration tax counter-argument was even more right than I thought at the

On Thu, Feb 21, 2013 at 12:37 PM, Claus Reinke <claus.reinke at>wrote:

> For the ES5 semantics of the interaction of the global scope and the global
>> object, how could you make this a static error? What would you statically
>> test? Would you statically reject the following program, where
>> <someExpression> is itself just some valid expression computing a value
>> (that might be the string "foo")? Note that "this" below is the global
>> object, since it occurs at top level in a program.
>> "use strict";
>> this[<someExpression>] = 8;
>> console.log(foo);
> My first reaction would be to reject the 3rd line statically. We can't
> hope to check dynamic scoping statically, but we could enforce
> safety of the language parts that look like they invoke static scoping.
> Either declaring 'foo' or logging 'this["foo"]' would be available as
> workarounds. So I don't see this example as an argument for a
> runtime error on the 3rd line.
> Claus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list