.json files with invalid json5?

[spyoungtech]

Hey there,

I'm running through these tests to test my own JSON5 parser. When running against the files in this repo, I noticed several files that (expectedly) errored out, but the filenames (with .json5) imply they should be valid.

Specifically:

• objects/reserved-unquoted-key
• misc/readme-example

Both of these files include reserved keywords as keys and are therefore invalid identifiers.

If my understanding is correct, should these should be renamed with a .txt extension?

Thanks!

P.S. I was also curious about octals... Currently my parser accepts them as integers with a leading 0. e.g. -0123 is -123. The spec doesn't seem to explicitly forbid leading zeros in integers. Though, perhaps I should bring this up in the spec repo.

[jordanbtucker]

Thanks for reaching out with your questions.

The files ending with .json5 are valid JSON5. So if you're parser is throwing on those, then I believe your parser is incorrect.

In the case of objects/reserved-unquoted-key and misc/readme-example, these both contain a key with the name while, which is a Keyword in ES5. However, while is only a Keyword in the context of Identifier, but object property names are always IdentifierNames, which does not preclude Keywords. In other words, Keywords can be object property names, but they can't be variable names.

The property names in JSON5 are IdentifierNames, so they can be Keywords too.

{ while: true } // This is a valid object in both ES5 and JSON5.

I should also warn you that this test repository is quite old, and it should probably be updated with the tests in the json5 repo. I recommend testing against those if possible.

Regarding octals, they are not supported in JSON5. Numbers in JSON5 derive from ES5's NumericLiteral, which only allows decimal and hexadecimal numbers, but not octals. (Note that a 0 must stand alone or be followed by a . or an x, but not another DecimalDigit.)

NumericLiteral only allows for octals in non-strict mode. The spec does not explicitly say that the referenced productions in ES5 should be parsed as if in strict mode, but that is implied by linking to the strict mode productions. The spec should be updated to be explicit on this matter though.

[spyoungtech]

Thank you so much for taking the time to make these clarifications. This has been really helpful.