parseInt and implicit octal constants

James Graham jgraham at
Mon Feb 23 07:38:50 PST 2009

David-Sarah Hopwood wrote:
> Allen Wirfs-Brock wrote:
>> Finally, there is another approach to resolving this issue.  Define a
>> new global function, parseInteger, that does the "right thing" and
>> relegate parseInt to Annex B.
> That's not a bad idea, given that parseInt has the additional flaw of
> silently stopping at the first invalid character, which this change
> will not fix. But it should be a "static" method of Number, not a global,
> to avoid further polluting the global namespace and potentially clashing
> with existing user functions.

It seems like having two functions with the same usecase but subtly 
different semantics contributes significantly to the cognitive burden of 
learning the language, and of reading other people's code, without — at 
least in this case — providing a huge number of clear cut benefits.

It seems like standardizing something that is theoretically nicer 
without any clear promise that implementations will converge on that 
behavior is not doing users any favours since they will still not be 
able to predict the behaviour of implementations they have not tested, 
rendering the specification pointless. That suggests to me that 
specifying the de-facto standard set by Microsoft/Mozilla/Apple here is 
the right way forward.

More information about the Es-discuss mailing list