> The reason never made much sense, anything can be abused (...)

I don't think your take makes sense. Comments were purposely left out of JSON to mitigate the problem described by Hyrum's law.

Smaller interface means a smaller surface to allow abuse. You're just arguing to facilitate abuse because you feel the abuse that was indeed avoided by leaving comments out is unavoidable, which is a self-contradiction.

On top of that,think about the problem for a second. Why do you feel it's reasonable to support comments in data interchange formats? This use case literally means wasting bandwidth with data that clients should ignore. The only scenario where clients are not ignoring comments if exactly the scenario that it's being avoided: abusing it for control purposes.

If you want a data interchange format to support that, you should really adopt something that is better suited for your whole use case.

> and your suggestion doesn't help with eg syntax highlighting tools for your config that will treat comments as syntax errors (...)

That's the whole point. This is by design, not a fault. Why are you pretending a language supports a feature it never supported and explicitly was designed to not support?

I think the opinionated approach is what made json “win” the format battle more than anything else. If you’ve been around enterprise in the early 00’s you’ll know the horror that XML became when people weren’t using it in any sane manner. Which a lot of people simply weren’t, for whatever reason. Now this is anecdotal but over the decades I’ve never had issues parsing json, and I largely attribute its strictness to that. Yes I suppose you could abuse it, but I wouldn’t have to parse your nonsense, which couldn’t be said for XML.

I don’t have anything against XML by the way, it was purely horrible to work with because people were using it in so many weird ways. Personally I prefer toml, but I guess we all have our preferences.

It is more that people made comments semantically important, e.g. a tool which did not interpret comments would not correctly interpret the data in the document.

This actually would put JSON in a worse place than XML - while XML has an overly complex infoset, that infoset is actually defined and standardized. Representing "a property with a comment on the property name and one before and after the property value" so that information is not lost in parsing would explode the complexity needed for an "interoperable" JSON library.

if someone wants to create some sort of scheme where they do "createdAt$date" as a property name to indicate the value is to be interpreted in some agreed-upon date format, that at least doesn't lose data if the JSON data doesn't understand that scheme, or require a new custom parser in order to properly interpret that data, compared to something like /* $type: date */ "createdAt" :...

I don't understand the problem. But I do understand the desire to keep the json definition simple and concise.

If you need additional fields in the json to hold comments, why not add the fields however you want? And if you need meta-data for the parser, you could add it the same way. In a project, i am working on right now, we simply use a attribute called "comment", for comments.

e.g. use "_" as a prefix to mark comments, and then tell you applications to ignore these attributes.

    {
    "mystring": "string123",
    "_mystring": "i am a comment for mystring",
    "mynum": 123,
    "_mynum": "i am a comment for mynum",
    "comment": "i am a comment for the entire object"
    }

This.

You can make special key names that are really directions for something.

You can make enrire k v pairs that are never used by anything that actually parses the json normally.

Argument was invalid as far as I can see and calling it "sorry it makes you sad" is, wow I don't even know where to begin with that.

Having annotation happen in a dedicated place designed for it is better than having it happen where it was not designed to be, end of math problem.

>and also lose the ability to roundtrip, so your app can't edit user configs

I think roundtrip with comments is not feasible in general. Most code just expects a hashmap, which it edits and then serializes back. You would need some really clever handling for comments to do it.

This is about interoperability and integrations. Which relies on some sense of predictability.

Syntax errors and erroneous highlighting are not even item 10000 on my list of JSON concerns.

Dare I pull a tired cliche and say “you’re using it wrong”