For a format designed to be human readable, JSON not supporting comments is a major let down. And not supporting trailing comma.
Please don't do that to JSON.
I think folding/lint/etc. markers are poor examples here, because they're basically annotations for other tools which seems entirely fine.
However comments that affect the behaviour of the code itself are really much less fun to deal with.
Worrying that JSON implementations would end up acquiring the latter is pretty fair given our track record as a species.
I agree, but those are extremely rare in my experience. SQL optimiser hints and HDL synthesis hints only affect performance.
What examples are there of comments affecting actual behaviour such that tools must parse them for the code to even run?
I can't think of any.
This sort of thing somewhat blurs the boundaries between affecting performance and affecting behaviour.
I'm not claiming that there's an obviously right answer here, only that there can be more questions about whether something is a good idea on net than people always consider.
Note: It would not surprise me to find that the actual motivation for leaving comments out of JSON went something like:
1) We can't have line comments because we don't want to be newline sensitive that way 2) If we do /* ... */ style comments people -will- write incompatible parsers for them no matter how carefully we specify them 3) Argh
but I wasn't there at the time, so the question will have to remain open.
I think there is no clear distinction between "hints for other tools" and "the behavior of the code itself" unless you implicitly assume a set of tools that define "the behavior of the code itself".
You could argue that HDL synthesis hints don't change the behavior of the code, nor do SQL optimizer hints.
I understand why you think that IDE folding hints are poor examples, but you would still force unrelated tools to leave those "comments" intact, possibly in cases where there is no clear definition of "intact" (massive transformations to the JSON structure). xkcd "spacebar heating" applies: https://xkcd.com/1172/
Sometimes deliberately leaving a potential feature out makes for a better end result. Sometimes it doesn't. But either way it's better to make the choice deliberately.
Comments were an explicit anti-feature. Douglas Crockford in 2012:
> I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability.
* https://web.archive.org/web/20120507104813/https://plus.goog...
* https://news.ycombinator.com/item?id=3912149 (discussion at the time)
And JSON primary purpose was to be a data interchange format; the fact that is human-readable text is a nice bonus.
As things are now trailing commas and comments would make JSON a better format, whether they were a good compromise at the time is not really the point.
I’d say not supporting large ints is worse.
https://stackoverflow.com/questions/209869/what-is-the-accep...