[phpnode]

that would be valid JSON, so it's not a problem. Standard tools can still parse it and reliably turn it into native objects. The same is not at all true when comments exist. People will start putting /* @annotations */ that can only be ready by certain tools which breaks the whole point of JSON - it's a data interchange format.

[MichaelGG]

That sounds smart on first pass, but doesn't really help. If people were going to use /* @annotations / and instead put them in keys, either way, the other side gets a document that isn't the one intended*. So regardless if it parses or not, it doesn't really help.

[phpnode]

Let's assume JSON supports comments, and `foo` is a JSON document with comments, what should happen here?

    JSON.stringify(JSON.parse(foo))

Presumably you'd say that it should return a plain JSON object without comments, right? However, with the current implementation this will return a JSON document that is identical to the input, modulo whitespace. This makes it easy to write tools that can, for example, increment the version number in a nodejs package.json file programatically. Doing this in a world where comments exist becomes extremely awkward or at the very least annoying, because either you have to write your own JSON parser that preserves comments, or you have to simply discard the comments when you're writing the file.

If you go with the first option, you'll inevitably run into a scenario where you have a document like this contrived example:

    {
      // this is the first ever version!
      "version": "1.0.0"
    }

And your tool goes off and increments the version number, so you end up with:

    {
      // this is the first ever version!
      "version": "2.0.0"
    }

and now your comment is a lie.

If you go with the second option, you destroy all comments whenever you write data back to the file, so they can be deemed temporary at best.

What benefit do you actually get from having comments in either scenario?

[swift]

Comments are appropriate in JSON which is written by humans. If it's written by a machine, of course comments are irrelevant. Situations where you need to automatically make changes to JSON which is primarily maintained by humans are a bit of a special case that I don't think is worth optimizing for; if you feel putting comments in object fields is a better choice in this situation, you can still do that even if comments are supported.

Supporting comments makes JSON more convenient to use in more situations, and it doesn't prevent you from doing anything you can do now.

[mercurial]

At least you can inspect the document you got with normal tools. Not so if you include comments.

And this may even encourage people into separating the data payload from the metadata, who knows?

[bronson]

That sounds like a "no true scotsman" argument. If comments were added to the spec then normal tools would support them just fine.

Besides, JSON has already become a common format for config files. Config files that don't allow comments are truly a step backward.

[mercurial]

> That sounds like a "no true scotsman" argument.

I don't see how this is a "no true scotsman". Maybe a non-true "no true scotsman"?

> If comments were added to the spec then normal tools would support them just fine.

Plain comments, sure. Comments with custom annotations in them, not so much.

> Besides, JSON has already become a common format for config files. Config files that don't allow comments are truly a step backward.

Maybe this wasn't such a good idea in the first place?

[MichaelGG]

How not? Comments with annotations would be ignored, just like a special annotation key. Either way, you'd end up with a parsed document that isn't what the original creator intended.

[Groxx]

If you had /* @annotations */ and JSON allowed comments, it would still be valid JSON to do so. Using "special" keys is identical then - both require special parsers / post-processors to properly reconstruct the data.