javascript - 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?

For instance:

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?

Answer 1

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

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