Early error on '0' followed by '8' or '9' in numeric literals does not seem to be web-compatible

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Aug 5 07:20:12 PDT 2014

On Aug 4, 2014, at 9:55 AM, Jason Orendorff wrote:

> On Mon, Aug 4, 2014 at 11:43 AM, Mark S. Miller <erights at google.com> wrote:
>> Isn't the early error required only for strict code?
There is actually no such Early Error in the ES6 spec, right?  We're talking about what the BNF allows. 

> Legacy octal integer literals are banned altogether in strict code. We
> implement that and have had no trouble with it.
> We're talking about something different here, legacy *decimal* integer
> literals starting with 0 and containing 8 or 9. As far as I know, no
> version of ES has ever permitted this kind of nonsense, but supporting
> it is apparently required for Web compatibility. (One more great
> reason to write all your code under "use strict".)

Just to be clear, FF rejects 08 in strict mode, and you don't intend to change that. Right?

We're only talking about Annex B, non-strict.  Right?

> Boris and I would like B.1.1 to be changed to match the horrible reality.

It would be great is somebody wanted to proposal the actual annex B language that is need to correctly describe the web reality semantics.  Otherwise, I have to prioritize this as an Annex B thing that browsers already have right, so it isn't all that important. That means it's lower priority than new ES6 features and I may or may not get around to fixing in in the ES6 spec.

Regarding, leading 0 constants in strict mode. The long term plan is to eventually make them legal decimal constants. The only reason not to do that now is because it might screw up people who are migrating non-strict web reality code containing octal constants into strict mode. 


More information about the es-discuss mailing list