parseInt(08) should work in sloppy mode?

[babel-bot]

Original issue submitted by @kangax in babel/babel#4757

Input Code

parseInt(08);

Babel Configuration (.babelrc, package.json, cli command)

{
  "sourceType": "script" // so that it's not strict
}

Expected Behavior

Should evaluate to 8.

Current Behavior

Throws SyntaxError.

Your Environment

software	version
Babel	6.17

[hzoo]

Hey @babel-bot! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

[oleksandr-kuzmenko]

hi, I started working on this issue and I have question: what behavior will be correct? 07 should be parse as octal, and 08 should be parse as decimal? should we support octal?

[danez]

I think we should do what spec is saying if it is speced. Otherwise we could see what other engines are doing. Node is doing this:

> 01
1
> 0111
73
> 0119
119
> 0119
119
> 0118
118
> 0117
79
> 022
18
> 099
99
> 'use strict'; 022
'use strict'; 022
              ^^^
SyntaxError: Octal literals are not allowed in strict mode.

> 'use strict'; 09
9
> 'use strict'; 08
8
> 'use strict'; 07
'use strict'; 07
              ^^
SyntaxError: Octal literals are not allowed in strict mode.

So it seems if 8 or 9 are part of the number which starts with 0 it is treated as decimal either strict or non-strict. At least that is the behaviour of node 6.10. Maybe you can look in the specs and see if this is correct.

[loganfsmyth]

Spec text is hard to read, but it is https://www.ecma-international.org/ecma-262/7.0/#prod-annexB-NonOctalDecimalIntegerLiteral

The important part is 08 is 8 and 09 is 9 AFAIK.

[bakkot]

08 should be parsed as 8 in non-strict mode (per B.1.1) and is a syntax error in strict mode:

A conforming implementation, when processing strict mode code, must not extend, as described in B.1.1, the syntax of NumericLiteral to include LegacyOctalIntegerLiteral, nor extend the syntax of DecimalIntegerLiteral to include NonOctalDecimalIntegerLiteral.

V8 fixed this pretty recently (but it's fixed in Chrome stable!), so I'm not surprised that node still gets it wrong.

cc @Alxpy; I think your PR accepts 08 even in strict mode.

[bakkot]

@loganfsmyth, you commented on the babel issue:

the open question here is if we should add a "web compat" flag or something

In my opinion, no. Just assume annex B is in effect. Since all browser JS engines implement it, and node implements it, there's no major environment in which it's disabled. And there probably never will be, since disabling it would Break The Web™ and new implementations usually want their syntax to match that of other implementations.

Use of annex B extensions is bad style, I think, but that's an issue for linters or (in some cases) strict mode, not a parser.