I intuit that the consequences are less harmful. Strict mode can trigger some syntax errors or throw runtime errors that wouldn't happen in non-strict code. Different arithmetic is less likely to cause this kind of problem.
Sure, it might not cause syntax errors, but it would cause subtle arithmetic bugs, that would be nigh impossible to find. Part of the good thing about "use strict" is that syntax errors "fail early". What you're talking about is a "fail really late and subtlely" type of error introduction, which makes me nervous.
Do you have an idea of a current running program that would behave significantly differently with an accidental bleed of arithmetic mode?
Seems like any JS which is doing math like for animations, bounds checking, etc, may be affected by such things. But I don't have any current code I could point to that I know for sure would die.
Are you refering to the pragma proposal [1]? I am not used to it, but if it's applicable, that's an idea too. [1] http://wiki.ecmascript.org/doku.php?id=harmony:pragmas
I wasn't specifically aware of/referencing that proposal. I was more getting at the idea that some kind of pragma/control command that could be "scoped" with { .. } would be useful, as opposed to the sort of "flag it on" type behavior of the "use strict" command. What makes "use strict" specifically frustrating is that there's no counter-part to say "use lazy" or "use legacy", so one it's encountered, there's no way to tell the interpreter to switch back out of strict mode, other than to get to a new file, which makes it harder to use concat for build performance optimizations.
--Kyle _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
