Add ignore_trailing_commas option

[chirsz-ever]

This PR adds ignore_trailing_commas argument to the detail::parser constructor, basic_json::accept, basic_json::parse and basic_json::sax_parse.

Why

In short: I totally agree with the JWCC extension.

After adding this, we can parse tsconfig.json, which allow trailing commas. (By the way, VSCode has a allowTrailingCommas option in its json schema configuration).

More projects would be attracted to use this library, e.g. R2Northstar/NorthstarLauncher#715.

Related issues: #1429 #1787 #1734

Detail Changes

• Add ignore_trailing_commas argument to the detail::parser constructor, basic_json::accept, basic_json::parse and basic_json::sax_parse.
• Update documets and README.md.
• Update the unit test "class_parser". Add , to non-empty objects and arrays for testing.

Pull request checklist

• The changes are described in detail, both the what and why.
• If applicable, an existing issue is referenced.
• The Code coverage remained at 100%. A test case for every new line of code.
• If applicable, the documentation is updated.
• The source code is amalgamated by running make amalgamate.

[coveralls]

coverage: 99.19% (+0.001%) from 99.189%
when pulling 481985f on chirsz-ever:chirsz/feat-allow-trailing-commas-2501
into 2d9a251 on nlohmann:develop.

[nlohmann]

Maybe the documentation should somewhere also mention JWCC - it's good when things have a name.

[chirsz-ever]

How do you think about combining the two options ignore_comments and ignore_trailing_commas into a single option to replace the current ignore_comments? For example, after the update, parse(str, nullptr, true, true) would allow both comments and trailing commas.

We can name the new combined option allow_comments_and_trailing_commas or enable_jwcc or relaxed_syntax or another better name.

I think that any user who choose to allow comments will not mind allowing trailing commas, and it is hard to imagine a use case where one must be enabled and the other disabled.

Regarding compatibility issues, this will not affect the serialization results, nor will it refuse to accept inputs accepted by previous versions. It will just accept some inputs that would not have been accepted before.

This solution is also conducive to adding new features in the future. But for me this is not important, because I only support adding two features of JWCC.

[chirsz-ever]

Maybe the documentation should somewhere also mention JWCC - it's good when things have a name.

Can I declare that this library would never add extensions (such as allow NaN as number, single quoted string, unquoted identifiers as object keys ...) other than JWCC in the future?

[nlohmann]

Maybe the documentation should somewhere also mention JWCC - it's good when things have a name.

Can I declare that this library would never add extensions (such as allow NaN as number, single quoted string, unquoted identifiers as object keys ...) other than JWCC in the future?

Never say never...

[nlohmann]

How do you think about combining the two options ignore_comments and ignore_trailing_commas into a single option to replace the current ignore_comments? For example, after the update, parse(str, nullptr, true, true) would allow both comments and trailing commas.

We can name the new combined option allow_comments_and_trailing_commas or enable_jwcc or relaxed_syntax or another better name.

I think that any user who choose to allow comments will not mind allowing trailing commas, and it is hard to imagine a use case where one must be enabled and the other disabled.

Regarding compatibility issues, this will not affect the serialization results, nor will it refuse to accept inputs accepted by previous versions. It will just accept some inputs that would not have been accepted before.

This solution is also conducive to adding new features in the future. But for me this is not important, because I only support adding two features of JWCC.

No, please leave it as is as it would change the behavior of existing code. Just like with the dump function, we need to figure out how to organize the great number of parameters in the future.

[chirsz-ever]

I combine the documentation about comments and trailing commas. Any more suggestions?

[nlohmann]

I combine the documentation about comments and trailing commas. Any more suggestions?

No, please leave it as is. We may combine this in the future, but right now, I would like the URLs of the documentation to not change (https://www.w3.org/Provider/Style/URI).

[chirsz-ever]

I combine the documentation about comments and trailing commas. Any more suggestions?

No, please leave it as is. We may combine this in the future, but right now, I would like the URLs of the documentation to not change (https://www.w3.org/Provider/Style/URI).

Could we just add a redirect rule to docs/mkdocs/mkdocs.yml as below?

       redirect_maps:
         'api/basic_json/operator_gtgt.md': api/operator_gtgt.md
         'api/basic_json/operator_ltlt.md': api/operator_ltlt.md
         'api/basic_json/operator_literal_json.md': api/operator_literal_json.md
         'api/basic_json/operator_literal_json_pointer.md': api/operator_literal_json_pointer.md
         'api/json_pointer/operator_string.md': api/json_pointer/operator_string_t.md
         'home/code_of_conduct.md': community/code_of_conduct.md
+        'features/comments.md': features/comments_and_trailing_commas.md

[nlohmann]

I combine the documentation about comments and trailing commas. Any more suggestions?

No, please leave it as is. We may combine this in the future, but right now, I would like the URLs of the documentation to not change (https://www.w3.org/Provider/Style/URI).

Could we just add a redirect rule to docs/mkdocs/mkdocs.yml as below?

       redirect_maps:
         'api/basic_json/operator_gtgt.md': api/operator_gtgt.md
         'api/basic_json/operator_ltlt.md': api/operator_ltlt.md
         'api/basic_json/operator_literal_json.md': api/operator_literal_json.md
         'api/basic_json/operator_literal_json_pointer.md': api/operator_literal_json_pointer.md
         'api/json_pointer/operator_string.md': api/json_pointer/operator_string_t.md
         'home/code_of_conduct.md': community/code_of_conduct.md
+        'features/comments.md': features/comments_and_trailing_commas.md

Yes, but please revert anyway.

[barroca]

Nice new feature. :)

[confluence]

Hi! Is there any ETA for this PR to be merged? Are any of the requested changes still outstanding? I'm very interested in using this feature in a work project (it would make it much easier for us to create a nice human-readable default configuration file). Thanks for everyone's work on this library!

[svnscha]

Hi! Is there any ETA for this PR to be merged? Are any of the requested changes still outstanding? I'm very interested in using this feature in a work project (it would make it much easier for us to create a nice human-readable default configuration file). Thanks for everyone's work on this library!

+1

[helgeklein]

Hi there, we would also need this. Is there an ETA?

[barroca]

@nlohmann are you ok with the changes now?

[nlohmann]

An entry like "- Added ignore_trailing_commas in version 3.12.1." is missing in the "Version history" section of docs/mkdocs/docs/api/basic_json/sax_parse.md.

[nlohmann]

@nlohmann are you ok with the changes now?

Yes, I just added a minor remark on the documentation.

[chirsz-ever]

An entry like "- Added ignore_trailing_commas in version 3.12.1." is missing in the "Version history" section of docs/mkdocs/docs/api/basic_json/sax_parse.md.

Done.

[nlohmann]

Looks good to me.

[nlohmann]

Thanks!