Future proof "use strict";

[Brendan Eich]

On May 22, 2009, at 2:54 PM, Michael Schurter wrote:

> Essentially my fear is that the meaning of "use strict" becomes
> ambiguous when future versions of ECMAScript are released (6 and
> beyond).

The Web doesn't rev just because a new edition of the standard comes  
out. If only we could use CPython's deprecating/obsolescence/from  
future import stuff. We can't, since old browsers persist for years  
and only go away unpredictably down the road.

So "use strict" has to mean in future years what it meant in the first  
year it appeared, absent explicit version selection.

You're right to note the possible version connection, but it is not  
mandatory. Users can say

"use strict";

in content targeting ES5 and downrev browsers, but need not opt into  
ES5 -- this is important for adoption. In other words, the above can  
and should appear in a <script type="application/javascript"> or even  
just <script> (no type attribute) tag. No RFC4329 ";version=..." MIME  
type parameter need be supplied, and current browsers don't all follow  
RFC4329 anyway.

With careful object detection and emulation (e.g., __lookupGetter__ as  
a fallback if Object.getOwnPropertyDescriptor is not detected), or  
just avoidance of new-in-ES5 features, the programmer nevertheless  
benefits from strict mode checking in the uprev browsers used for  
development and (some) testing.


> What seems reasonable for both ES users (webdevs) and implementors is
> for ES engines to support only 2 modes: strict and permissible,
> supporting fine-grained per-ES-version language support would cause
> undue complexity for implementors.

Yes, that's true.


> However, when ES users enable the strict mode, they have a specific ES
> version in mind (right now 5, but in the future perhaps 6, 5.1, etc).

If they do and the version changed strict mode -- which is possible,  
we've talked about strict mode becoming stricter over time -- then  
(and only then) will an explicit version selection pragma or MIME type  
parameter be required.

But as with Perl, we hope that simple, version-free "use strict" will  
suffice for a long time.


> Based on the 2 reasonable modes model I describe above "strict ES v5"
> should be evaluated in the *permissible* mode by future ES versions.

That's wildly optimistic. We have no idea when, if ever, a random  
string literal expressed as a useless statement might be safely  
interpreted to enable an incompatible mode of the language. It's  
unlikely any such code exists, but it is overtly incompatible.


> Therefore, ES users need a way to define an ES *version* to target.

Maybe, maybe not. We shouldn't assume this and over-couple "use  
strict" and a "use version".


> This could be as simple as:  "use strict 5"; which could even be used
> alongside the current "use strict"; right now.
>
> A more robust model might be to allow the mode to be defined in a
> conditional statement:
>
> if (ecmascript.version <= 5) "use strict";

The pragma is a compiler directive, a static property of code, and so  
must come first in a program or function body. It's not a runtime  
directive. You can't change to strict mid-parse, let alone at runtime.


> As a side note, it would be nice if some sort of strictness stability
> were to be guaranteed like API/ABI stability within major ES versions.
> So that ES 5.1 strict == ES 5 strict != ES 6 strict.

There won't be a 5.1 -- again we are not CPython, standards committees  
don't do minor or patch releases, and the Web moves slowly.

Definitely the notion of strictness should be stable. We don't know  
yet that we could make an ES6 "use strict" any stricter for existing  
content. It might be that doing so would, in that future year, "break  
(too much of) the Web". Even if there were explicit version selection  
(probably there will have to be for ES6, to hide new syntax from old  
user agents), if the migration tax is too high for a proposed  
"stricter" strict mode, it may not fly.

But for ES5 we are not getting into versioning. As noted previously,  
there are at least two aspects to versioning: <script> version,  
defaultable via an HTTP header (expressible with <meta http- 
equiv=...>); and "frame version" for the shared object model in the  
whole window or frame that loads content including scripts.

/be