I like crockford's suggestion. if you need these features, write javascript. (or something akin to json5), and run it through a minified, or eval it in a javascript sandbox to convert it to plain json.
So the suggestion for comments in JSON is "don't use JSON"? That's a dumb suggestion, and defeats the entire point of having JSON in the first place. No common formatting/tooling/parsing library can work with the config file if it has a comment. Every app wanting to allow comments needs to go get a full JavaScript EE and parse them as JS? That's absurd.
So this proposal is coming back and fixing that silly limitation.
The suggestion for comments was to use JSMin to process them out before handing it over to the json parser.
That is, if you really want comments, crockford says, go ahead and add them. Just remember to remove them before parsing as JSON. Which is actually not that hard. you can even do it with sed. Just for the love of crock don't put processing directives in the comments.
"Just remember to remove them"... in other words, don't use JSON. If you have to preprocess it with another program first, then you might as well use another format anyways.
> If you have to preprocess it with another program first, then you might as well use another format anyways.
What?? By that logic, you might as well hand-write x86 assembly, since C requires a "preprocessing" step (some might call that compilation).
Using "JSON5" as a human-writable format for storage and then compiling it to real JSON before going over the wire seems like the best of both worlds to me. The wire format benefits are preserved, the format is validated as a side effect of compilation, and you get to write in a well-defined language with comments and bareword-identifiers. Your objection is that you don't want to run a compiler, so you'd rather send JSON5 over the wire?
> dumb suggestion .. defeats the entire point of having JSON in the first place
No. Json's mission is to be a wire protocol. You're suggesting using it for other purposes, and in a way that compromises its role here as a wire protocol. It's not intended to be a multi-purpose serialisation format.
Hand-hackability and simplicity is why we use JSON. These changes definitely make things better for humans.