JSON5.parse("{1:true}"); about json5 HOT 10 CLOSED

Yep — this in invalid JS too:

> {1:true}
SyntaxError: Unexpected token :

Unquoted keys have the same rules as variables ("identifiers"). Here's a reference:

https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Core_Language_Features#Variables

I'll update the readme to be clearer about this.

from json5.

Oh! Sorry

from json5.

No worries. =)

from json5.

{1:true} is a valid JS object.

An example of this notation can be found on the link you posted in the "String literals" chapter:
https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Core_Language_Features#Object_literals

from json5.

This is currently working for me. From the node prompt:

> require('./json5').parse(require('./json5').stringify({1:true}))
{ '1': true }

If there's something unexpected, then please raise a new issue.

ps- you are correct that {1:true} is valid JS.

from json5.

require('./json5').parse('{1:true}') doesn't work. I don't know whether it counts as unexpected or not.

from json5.

Yes, you're right @rlidwka:

> {1:true}
SyntaxError: Unexpected token :
> ({1:true})
Object {1: true}

(Interestingly, the first case gives that syntax error in Chrome, but not Node.)

That we reject this is currently expected, because I was under the impression that ES5's spec on object keys applies the same rules for unquoted keys as it does to variable names (hence the link I shared above).

If it's valid ES5 though, perhaps we should allow this... It'd be nice to confirm that this is allowed per ES5 though, not just an "it-so-happens" behavior of existing implementations.

from json5.

(Interestingly, the first case gives that syntax error in Chrome, but not Node.)

It can happen because first "{" is treated as a beginning of a block (as in {var x=0;}), not as an object.

If you want to test such kind of things reliably, add parentheses around the statement. This: ({1:true}) should work everywhere.

from json5.

Yep, I'm aware of the ambiguity, I was just surprised that two different instances of the same JS implementation treat the ambiguity differently.

from json5.

Closing as JSON5 will not support numeric literals as property names until there is enough demand for it. #55 is now the official issue regarding this.

from json5.