When I read the spec, there is one point I found somewhat unclearly specified: are identifiers in object keys meant to be a short-hand for strings, or something that should remain separate after parsing & re-serializing? (If discounting lost formatting)
I assume they are just meant as a short-hand, since the JSON5Value list seems to indicate what is meant to be returned after parsing:
A JSON5 value must be an object, array, string, or number, or one of the three literal names true, false, or null.
JSON5Value:
JSON5Null
JSON5Boolean
JSON5String
JSON5Number
JSON5Object
JSON5Array
After all, the single quote strings aren't in there either. Also the spec speaks of collision between "names" and not strings and identifiers separately. However, it would be nice if the 3. Objects section could clarify this and state without a doubt that the two different ways to write a name are just syntactical sugar that is usually in both cases expected to result in a plain string after deserialization.
When I read the spec, there is one point I found somewhat unclearly specified: are identifiers in object keys meant to be a short-hand for strings, or something that should remain separate after parsing & re-serializing? (If discounting lost formatting)
I assume they are just meant as a short-hand, since the JSON5Value list seems to indicate what is meant to be returned after parsing:
After all, the single quote strings aren't in there either. Also the spec speaks of collision between "names" and not strings and identifiers separately. However, it would be nice if the
3. Objects
section could clarify this and state without a doubt that the two different ways to write a name are just syntactical sugar that is usually in both cases expected to result in a plain string after deserialization.