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 parseInt(value)
.
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.
When ToNumber
is applied to the String Type a special grammar production is used, called the StringNumericLiteral
.
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" NumericLiterals
.
A StringNumericLiteral
:
- 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 parseInt
and parseFloat
functions.
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 (OctalIntegerLiteral
and OctalEscapeSequence
) were removed from the grammar of NumericLiteral
s 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.
But why?
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 parseInt
-.
Now, under strict mode an octal literal will cause a SyntaxError
exception -currently only observable in Firefox 4.0 Betas-.