You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
ell1e
changed the title
Suggestion to clarify: are identifiers in object keys meant to be a short-hand for strings or separata things to be retained?
Suggestion to clarify: are identifiers in object keys meant to be a short-hand for strings or separate things to be retained?
May 13, 2020
Good point. You are correct that abc, 'abc', "abc", and \x61\x62\x63 are all variations of the same "name". This should be clarified in the spec.
jordanbtucker
changed the title
Suggestion to clarify: are identifiers in object keys meant to be a short-hand for strings or separate things to be retained?
Clarify uniqueness of property names
May 13, 2020
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.The text was updated successfully, but these errors were encountered: