Support for comments.

[TurpentineDistillery]

One of the biggest gripes people have with json format is the lack of support for comments.
E.g. see this reddit thread.

Many libraries, including jsoncpp and RapidJSON have support for comments in spite of the RFC.
Additionally, RapidJSON allows further relaxations to grammar, e.g. trailing commas and nan/infinity for fp-numbers.

If we want to be user-friendly, perhaps we shouldn't alienate users that have need for comments in their config files?

[nlohmann]

For this library, we do not plan to support any input which is not compliant to RFC 7159.

See #363, #311, #294, #192.

[nlohmann]

Another argument (I think) against comment support would be that the library then should preserve comments so that they do not disappear in the serialization.

[TurpentineDistillery]

Understood. But it the case you decide to support the comments, such support, by definition; should only entail ignoring them in the input; preserving them should definitely not be in scope.

[jschmidt42]

I agree that it would be nice if the library could ignore comments when parsing JSON. Maybe json::parse could add a parameter flag do allow non-standard additional parsing options. Similar to the options used by this lib as an example: https://github.com/niklasfrykholm/nflibs/blob/master/nf_json_parser.c#L22

[nlohmann]

I know how I would realize this feature. But I do think that this library is better off without comments.

[rokups]

I would like to reiterate that a more liberal parser is a desired feature. Comments are not a standard feature therefore it would be completely acceptable if they were not preserved. This library is my first pick for json parsing, however lack of comment support or even inability to ignore comma after last } is a dealbreaker. I hope enough people will voice their concerns so that this feature can be reconsidered.

[tomba]

I'm about to start hacking on the library to support trailing commas (although I have no idea where to start looking =) ). When dealing with config json files it drives me nuts that I need to constantly tweak the commas. And comments would make those config files much more readable.

[OvermindDL1]

I'm about to start hacking on the library to support trailing commas

I thought that was specifically disallowed by the JSON spec?

If you are using them as a config file or so then why not use TOML or HOCON or something?

[tomba]

I'm about to start hacking on the library to support trailing commas

I thought that was specifically disallowed by the JSON spec?

Could be, but I don't see any harm with that as it still parses json written per the spec. Especially in config files, which are not parsed by anyone else but my application.

If you are using them as a config file or so then why not use TOML or HOCON or something?

Thanks, I wasn't aware of HOCON. I need to have a look. I did try TOML, but I didn't move to it. I can't recall what was the issue, but possibly the main issue was that this json library is great, and I anyway need it for parsing received json data. So having additional library which is more difficult to use than this does not sound good. Especially if the only missing piece is the trailing commas =).

[nlohmann]

The harm in relaxing standards is IMHO nicely described in The Harmful Consequences of the Robustness Principle.

[kenjichanhkg]

I like the library, and was planning to use it to load config files. My company wants to put comments in json file. But it doesn't support/ignore comment, and is stopping me using it.

[nlohmann]

You should tell your company that the JSON format does not support comments, and forcing you to do so limits the number of libraries - not only in C++.

[ceztko]

For anyone up for a challenge, I suggest inheriting std::istream by wrapping another source std::ifstream (or another std::istream), piping content from source and removing non compliant comments. Be aware: I did once for other purpose and it's not trivial. Good starter point here[1].
Time estimate for this task: 1-2 working days with good confidence in working with STL library internals. Quite more time without.

[1] https://stackoverflow.com/a/12114421/213871

[LinuxRocks2000]

Seriously, what harm could comments do? The implementation would not harm the library, and it would make JSON a lot more usable, especially in large scale apps with teams of developers who all want to mess with configuration files.

[nlohmann]

The problem is portability. JSON does not support comments.

[rokups]

It is not a problem if feature is opt-in.

[nlohmann]

It is, because then this library would accept more than just JSON. And that JSON+x would not be portable any more. I'm sorry, but https://github.com/nlohmann/json#comments-in-json is all I can add to that.

[rokups]

This library already accepts more than json.

[nlohmann]

You mean the formats CBOR, MessagePack, etc.? These are independent of JSON.

[ceztko]

I think the library could provide an hook to introduce non standard behaviors (like a way to process tokens in advance and substitute then): that way the library itself would be clean of any "heretic" interpretation. But I understand if the author is not interested, then he should not do it. Also, it would introduce a small performance penalty.

[rokups]

Anyhow as long as it is opt-in i see no issue with incompatibilities. If people explicitly opt in i trust they understand what they are doing. And this blatant refusal without a compelling argument seems stubborn.

For anyone who wants json with comments: https://github.com/Tencent/rapidjson/

[robiwano]

JSON now has support for comments in the standard. https://json5.org/

[nlohmann]

That is not JSON (as of RFC 8259), but slightly related standard.

[robiwano]

Hmm... I realize though that since you use std::map in the DOM, supporting comments would not only not according to RFC 8259, but damn near impossible. Since I need a format that can annotate settings, and be read AND writeable, I might need to find another solution.

[nlohmann]

I'm not sure what this has to do with std::map.

[robiwano]

Since it is ordered. How would an implementation know how comments, or annotations, are related to the respective fields? A write could easily destroy this.

[nlohmann]

I see.