Why doesn’t an octal literal as a string cast to a number?
+, why not an octal?
1000 === +"1000" // -> true 0xFF === +"0xFF" // -> true 0100 === +"0100" // -> false - +"0100" gives 100, not 64
I know I can parse with
parseInt("0100" [, 8]), but I’d like to know why casting doesn’t work like it does with hex and dec numbers.
Also, does anyone know why octal literals are dropped from ECMAScript 5th Edition in strict mode?
I’m a bit late to the question but I think I can give a good answer.
The accepted answer doesn’t tell you anything more that what you actually know, and mention in the question itself:
Number(value) works as
+value but not as
The key is to know that there is a semantic difference between type conversion and parsing.
Why does an octal number string cast as a decimal number?
Because the Number constructor called as a Function (
Number(value)) and the Unary
+ Operator (
+value) behind the scenes use the
ToNumber internal operation. The purpose of those constructs is type conversion.
ToNumber is applied to the String Type a special grammar production is used, called the
This production can hold only Decimal literals and Hexadecimal Integer literals:
... StrNumericLiteral ::: StrDecimalLiteral HexIntegerLiteral ...
There are also semantic differences between this grammar and the grammar of “normal”
- May be preceded and/or followed by white space and/or line terminators.
- That is decimal may have any number of leading 0 digits. no octals!
- That is decimal may be preceded by + or − to indicate its sign.
- That is empty or contains only white space is converted to +0.
Now I will go with the
The purpose of those functions obviously is parsing, which is semantically different to type conversion, for example:
parseInt("20px"); // 20 parseInt("10100", 2); // 20 parseFloat("3.5GB"); // 3.5 // etc..
Is worth mentioning that the algorithm of
parseInt changed in the ECMAScript 5th Edition Specification, it no longer interprets a number’s radix as octal just for having a leading zero:
parseInt("010"); // 10, ECMAScript 5 behavior parseInt("010"); // 8, ECMAScript 3 behavior
As you can see, that introduced an incompatibility in the behavior between ES3 and ES5 implementations, and as always is recommended to use the radix argument, to avoid any possible problems.
Now your second question:
Why octal literals are dropped from ECMAScript 5th Edition in strict mode?
Actually, this effort of getting rid of octal literals comes since 1999. The octal literal productions (
OctalEscapeSequence) were removed from the grammar of
NumericLiterals since the ECMAScript 3rd Edition specification, they might be included for backwards compatibility (also in ES5) with older versions of the standard.
In fact, they are included in all major implementations, but technically an ES3 or ES5 compliant implementation could choose to not include them, because they are described as non-normative.
That was the first step, now ECMAScript 5 Strict Mode disallows them completely.
Because they were considered to be an error prone feature, and in fact, in the past they caused unintentional or hard to catch bugs — just as the same problem of implicit octals of
Now, under strict mode an octal literal will cause a
SyntaxError exception — currently only observable in Firefox 4.0 Betas —.
Because you’re not actually performing casting in the proper sense (JS doesn’t have casting) – it’s just type juggling.
"foo".toUpperCase() for example, is replaced by the evaluation of code that would roughly look like this
new String( "foo" ).toUpperCase();
Since strings can’t be evaluated with a unary
+ operator, JS converts your string to a number – and it doesn’t use
parseFloat() internally – you guessed it – it uses
So, the value you see is the what you’d see from the return of Number(), which doesn’t appear to assume octals.
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.
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 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.)