Search Terms:
numeric separator
spec test for checking leading zero separated literal
Code
These literals should be invalid:
0_0
0_0.0
0_0e0_0
0_0_1
but this should valid:
1_0.0_1 // 10.01
1_0e0_1 // 100
Expected behavior:
SyntaxError: Numeric separator can not be used after leading 0.
Actual behavior:
0_0 // -> 0 valid but shouldn't
0_0.0 // -> 0 valid but shouldn't
0_0e0_0 // -> 0 valid but shouldn't
0_0_1 // -> 1 valid but shouldn't. Btw 001 is invalid in strict mode
1_0.0_1 // -> 10.01 ok
1_0e0_1 // -> 100 ok
Browsers have different behavior in case of 00_1 or 077_77:
Chromium reports Uncaught SyntaxError: Invalid or unexpected token (for 0_1 reports Uncaught SyntaxError: Numeric separator can not be used after leading 0.)
SpiderMonkey reports Uncaught SyntaxError: numeric separators '_' are not allowed in numbers that start with '0'
Currently TS parses it as 2 tokens: NumericLiteral 00 (with Octal flag) and Identifier _1 (because scanOctalDigits will stop on _) and therefore reports 2 errors: Octal literals are not allowed in strict mode. and Cannot find name '_1'.
Question is: Should fix for this issue should handle only cases 0_ (and process 00_ as it currently does) or 00_ as well (and report error similar to one from SpiderMonkey)? If later - this might break bad code.
_UPD._ Strange that TS doesn't report An identifier or keyword cannot immediately follow a numeric literal. for 00_O1 but does for 0_O1.
@RyanCavanaugh I'd like to take on this issue.
According to spec test it should be an syntax error so I'll update scanOctalDigits to skip over _ or just use scanBinaryOrOctalDigits.
This will be "breaking change" for already invalid code.
Strange that TS doesn't report An identifier or keyword cannot immediately follow a numeric literal. for 00_O1 but does for 0_O1.
Will create separate issue to report errors in this case.
Do you have any objections?
If that "breaking change" is not feasible - fix for An identifier or keyword cannot immediately follow a numeric literal. error should be noticeable enough for cases like 00_1 or 077_77
P.S. I hope @a-tarasyuk doesn't work on this one ๐
@IllusionMH I think that sounds reasonable, I don't expect it to be a large breaking change but we can run the test suite
Not sure that I understood the point to mention me in this issue ๐ . As I know, if the issue marked with the Backlog/Help Wanted/GFI label anyone can try to resolve it, maybe I'm wrong and @DanielRosenwasser :point_left: can better clarify the current process. I do PRs from time to time _(I can't even say that I did a lot of PRs :worried:)_, however, I definitely cannot work on all issues :joy:, unfortunately ๐ .
UPD. Somehow I managed to write this one ambiguous too ๐คฆโโ๏ธ. Clarifications in cursive.
@a-tarasyuk It was some kind of _positive_ joke and my real hope that I will have chance to submit PR this time because IMHO you fix a lot of issues and do it quickly (_which is great_, previously beat me by 2 minutes in other issue with a bit better solution :+1: _and I learned new thing_).
I also agree think that everyone can submit fix for these kinds of issues. Thank you for a bunch of submitted fixes, some of them I rely on every day! ๐
I'm sorry if that mention was inappropriate and for ping.
As for this issue - I have fix for numbers starting with 08... and 09, and plan to finish "legacy octal literals" this weekend.
Yeah, I understood it as a joke in a positive light - as in "@a-tarasyuk fixes a lot of issues really fast, I hope I can fix this one first!"
For what it's worth, we all really appreciate working with both of you on this issue tracker, so thank you both! Please don't feel bad about either of your contributions.