Support for trailing commas

[bempelise]

It looks that the current parse function throws an out_of_range exception when a trailing comma is detected e.g.:

{
    "var": "value",
    "var2": "value2",
}

The above works fine if the comma after "value2" is removed.

I know that the trailing comma is not allowed in the original json specification but I think that it is going to be allowed in future ones and it seems to me an unnecessary inconvenience.

Would you consider allowing this in your library?

[jaredgrubb]

This has been discussed before (eg, #376 ) and in the README (https://github.com/nlohmann/json#comments-in-json). Although these are both about comment support in JSON, the same rationale applies to trailing-comments.

[nlohmann]

Duplicate: #1429 #376

[bempelise]

So to rephrase that, will there be support for JSON5?

[nlohmann]

Not in this library. I currently do not have the time to invest in JSON5.

[bempelise]

Thanks, do you know any C++ Json library that supports it?

[nlohmann]

No, but I hardly have heard of anyone using JSON5 for that matter. I think going to YAML could be a better idea, as it has wider support.

[sebastienandary]

Hi!

the same rationale applies to trailing-comments.

Did you mean trailing-commas ? Because json comments actually are supported so that would mean there is no more reason to not support trailing-commas, right ?

[nlohmann]

Both a trailing comma and a comment are syntax errors in JSON. But I understand the rationale of having comments in JSON, so I eventually added support for them. I still lack the understanding why trailing commas should be supported, though.

[sebastienandary]

• Diff contents are cleaner and more accurate
• We have a lot of hand written and often modified data files. The lack of trailing commas support induces slightly more keyboard operations for a significant ratio of all modifications our users do (typically a copy pasted block needs modifications just before and just after it). Small things that sum up to be annoying for a lot of people in the end.

[d4r1u5]

Just hit this issue myself, but wanted to add that I found the "ignore comments" flag to parse() to be a pretty simple solution for balancing that interoperability/usability situation. Seems like "ignore trailing commas" could be a similar nice-to-have. Might even make sense as additional functionality behind the current "ignore" flag, as most callers of that signature are probably okay with interop tradeoffs.