Future proof "use strict";
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.
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!
I'm just a lowly Python/JS webdev eager to use ES5. John Resig encouraged me[1] to post this suggestion, so blame him if its no good. ;-)
For the record: my 2 original comments on "use strict" [2] [3]
Essentially my fear is that the meaning of "use strict" becomes ambiguous when future versions of ECMAScript are released (6 and beyond).
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.
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).
Based on the 2 reasonable modes model I describe above "strict ES v5" should be evaluated in the permissible mode by future ES versions.
Therefore, ES users need a way to define an ES version to target. 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";
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.
Like I said, I could be way off base here. I'm joining the discussion a bit late and only from the perspective of an ES user. :-)
Michael Schurter schmichael on IRC, Twitter, etc
[1] ejohn.org/blog/ecmascript-5-strict-mode-json-and-more/#comment-385042 [2] ejohn.org/blog/ecmascript-5-strict-mode-json-and-more/#comment-384967 [3] ejohn.org/blog/ecmascript-5-strict-mode-json-and-more/#comment