[lolinder]

But they're not two different formats—they're two different jobs being done by the same format.

JSON as currently spec'd is honestly quite bad at both jobs, but the most rational defense of its use as a data format is that it's (mostly) human readable. Given that that's its main value proposition, what exactly is the reason for saying that JSON-as-data-format should not have comments? What do we lose if we allow them?

[throw0101d]

> Given that that's its main value proposition, what exactly is the reason for saying that JSON-as-data-format should not have comments? What do we lose if we allow them?

Because JSON originally did have comments, and people were putting pragmas into them, and so different parsers would act different depending on whether they understood them or not. Comments ended up being an anti-feature in JSON because people were abusing them.

Source:

> I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. […]

* https://web.archive.org/web/20190112173904/https://plus.goog...

[Cpoll]

I don't buy it, what's stopping people from putting pragmas in key:value pairs? There's a chance of collision, but you're already deciding to sacrifice interoperability, so just accept that the myJson spec says '___declare___' is a reserved key.

[jakeogh]

If I parse json, I dont want to lose data. Having the parser read the comments (however they are, as long as they are in spec and therefore read by the parser) is a good thing. Having to parse the file again, with a fuzzy out-of-spec system (looking for comments) is clearly worse. The whole point of json is to serialize stuff, breaking that to insert non-machine readable comments makes the spec less reliable.

[staz]

You cut the rest of his comment

> Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.

Doesn't seems he is that against the idea

[tom_]

What are some examples of people doing this?

[m463]

> but the most rational defense of its use as a data format is that it's (mostly) human readable

I would call out portability instead, which is not dependent on the byte ordering or endianness issues of binary data formats.

sort of like: javascript is portable code, json is portable data.

[sophacles]

I think json should allow comments.

But there are dangers there - look at how horribly comments get abused in code:

* doctests are nonsense, just write tests. (doctests like rusts that just validate example snippets are the closest thing to good I've seen so far, but still make me nervous).

* load bearing comments that code mangling/generation tools rely on (see a whole bunch of generated scripts in your linux systen - DO NOT EDIT BELOW THIS LINE)

* things like modelines in editors that affect how programs interact with the code

* things like html or xml comments that on parsing affect end user program logic.

Comments can be abused, and in something like JSON on the wire I can see systems which take additional info from the comments as part of the primary data input. Often a completely different format... and you end up with something like the front-matter on your markdown files as found in static site generators.

Point being, comments are not a purely benign addition.

[mschuster91]

> see a whole bunch of generated scripts in your linux systen - DO NOT EDIT BELOW THIS LINE

these are mostly a warning sign for humans, to be read as "if you need to modify the script below this line, a) you gotta be knowing what you're doing, we are not held liable for support if you change stuff around there b) please contact us to make sure we didn't miss a legitimate need or c) you're trying to do something in a bad way and there's better ways to do so".

[Cpoll]

I feel like most of your examples of "abuse" are just getting things done.

I don't see anything intrinsically wrong with doctests. I also can't see a better way to do "load bearing comments," and I'm not eager to go back to "Step 2: Edit your .bashrc to include foo."

[pulsarmx]

How is abusing comments any different than abusing a top-level property with a key like “__comment”?

[amatecha]

at least a top-level metadata property can be explicitly defined in a .json.schema[0] and formalized, rather than being some kind of ad-hoc pre-processor step you have to evaluate before actually using the JSON data. I didn't even know about that approach before I read your comment but it instantly makes more sense to me in terms of maintainability and interoperability.

[0] https://json-schema.org/

[michaelmior]

> doctests are nonsense, just write tests

Why are doctests not tests?

> doctests like rusts that just validate example snippets are the closest thing to good I've seen so far

Rust's doctests don't seem to be fundamentally different from Python doctests, which is the language I've seen most commonly make use of doctests.