Why doesn't an octal literal as a string cast to a number?

Question

In JavaScript, why does an octal number string cast as a decimal number? I can cast a hex literal string using Number() or +, why not an octal?

Answer 1

To elaborate on why octal support was removed in ES5, it's mostly because, to the novice or non-programmer, the syntax is unexpected. Imagine vertically aligning a series of numbers (perhaps being added), using leading zeroes to align them, for example -- if your numbers don't use 8 or 9, they'll end up being treated as octal. Suddenly your code's off in the weeds for no obvious reason! This is why octal support was removed. A different octal syntax might someday be added if it doesn't create such a misfortune (I think I remember seeing 0o755 as one strawman idea), but for now octal is out.

Regarding the incompatible parseInt change noted in past responses: no implementation has made this change, and I suspect no implementation will make it. ES5 is mostly grounded in reality. Its new features generally don't break existing code (except that new code of course must take care in using new features not to break existing code as part of that use) that doesn't try to use the new features. Its incompatibilities are mostly negligible as well, or they're irrelevant because real-world implementations blithely ignored the specification for compatibility reasons. But not all the incompatibilities are well-founded: some are more aspirational than harmonizing. The change to parseInt is an example of an aspirational change. It breaks existing code that expects octal syntax, without an explicit radix, to parse as octal.

For the span of a few days SpiderMonkey (Mozilla's JavaScript engine) implemented a halfway-change to make parseInt, when called from strict mode code, disregard octal, and to support octal when not called from strict mode code. This is closer to what ES5 wants, but it's a clear impediment to converting non-strict code to strict mode, it would likely be confusing to the user, and -- perhaps most interestingly for implementers -- it means you couldn't implement parseInt in JavaScript itself (because there's no way in the specification to examine the strictness of one's calling function), as might be desirable at some future time (to reduce attack surface, ease implementation, and so on). So we undid the dependency. (I wrote the patch to make parseInt caller-dependent, and I reviewed the patch to undo it, spawned by further discussion after my initial patch landed.) parseInt now conforms to ES3 again, and given the web as it is, and that ES5's semantics are probably not compatible with it, I doubt we'll change. Therefore I doubt others will change, either. (I'm also pretty sure they'd agree with our estimation of the degree of incompatibility of the web with ES5's aspirational forbidding of implicit octal syntax in parseInt, and probably with our other reasons too. Even if we were to change I'm not sure they would follow, and I suspect they'd be smart not to.)