Future proof "use strict";

[Michael Schurter]

On Fri, 2009-05-22 at 15:26 -0700, Brendan Eich wrote:
> 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".

The above makes sense.  Thanks for the thorough and patient
explanation.  :-)

> > 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.

Huh, I guess I assumed since you could change it depending on context
(eg within a function) as per John's post it was configurable at
runtime.  So you couldn't do:

(function() {
    var main = function() { /* do stuff here */ };
    var strict = function() {
        "use strict";
        main();                        // <-- A
	eval("("+main.toString+")()"); // <-- B
    };

    // Pretend ecmascript.version exists or a library to detect 
    // the ES engine's capability is used.  :-)
    if (ecmascript.version <= 5)
        strict();
    else
        main();
})();

Is strict mode only enabled inside strict(), but never inside main()?

I'm guessing the code inside A is executed outside the strict context in
A, but I'm unsure of what B would do (scary code indeed).

> > 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

Once again thanks for the thorough and patient explanations.  I was
thinking under a number of wrong assumptions and just plain wrong.  :-)

Looking forward to using this feature!

-schmichael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090522/f83b2e1b/attachment-0001.bin>