A directive to solve the JavaScript arithmetic precision issue

Kyle Simpson getify at gmail.com
Mon Aug 15 12:32:59 PDT 2011

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



More information about the es-discuss mailing list