9.1.3.1 - ToNumber Applied to the String Type
The spec needs to be updated to support OctalIntegerLiteral and BinaryIntegerLiterals in the Number function
assert(3 === Number('0b11'))
assert(63 === Number('0o77'))
At the April 2014 TC39 meeting we convinced ourselves that that it would be an undesirable breaking change for parseInt to recognize these new forms. https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-04/apr-9.md#46-updates-to-parseint
I don't really see why it would be any better for Number to accept them.
Number(s) has always been the reverse of Number.prototype.toString. It is used to accept valid number literals as text. Therefore it should continue to match the syntax of number literals.
(In reply to comment #2)
> Number(s) has always been the reverse of Number.prototype.toString.
How so, ES<6 N.p.toString doesn't produce HexIntegerLiteral (or legacy OctalEscapeLiteral)
> It is used
> to accept valid number literals as text. Therefore it should continue to match
> the syntax of number literals.
I don't see anything in previous editions that says that ToNumber (or the Number constructor that is defined in terms of ToNumber) matches the same syntax as the ECMAScript Language NumericLiteral. In fact, ToNumber has always had it's own distinct grammar.
Just like for parseInt, changing the ToNumber grammar could be a breaking change for some existing code.
(In reply to comment #3)
> (In reply to comment #2)
> > Number(s) has always been the reverse of Number.prototype.toString.
>
> How so, ES<6 N.p.toString doesn't produce HexIntegerLiteral (or legacy
> OctalEscapeLiteral)
You are right. I don't know what I was thinking.
>
> > It is used
> > to accept valid number literals as text. Therefore it should continue to match
> > the syntax of number literals.
>
> I don't see anything in previous editions that says that ToNumber (or the
> Number constructor that is defined in terms of ToNumber) matches the same
> syntax as the ECMAScript Language NumericLiteral. In fact, ToNumber has always
> had it's own distinct grammar.
But these grammars have always been in sync.
> Just like for parseInt, changing the ToNumber grammar could be a breaking
> change for some existing code.
I think it is not fair to compare with parseInt. parseInt is very lenient. It accepts any kind of junk at the end of the string. Number has always only accepted strings that fully matches the grammar.
I would like to resolve this soon. Maybe we can take this up again at the face-to-face meeting next week?
Marking as IN_PROGRESS as per the September 23 meeting.
sorry, for ES6 drafts "IN_Progress" means that the fix has been integrated into the editor's current working drat.
Setting status back to "Confirmed"
Fixed in rev 28
*** This bug has been marked as a duplicate of bug 3259 ***