Thoughts on adding JSON as a serialization format

[badtuple]

Are there any opinions on adding JSON as a serialization format? My project uses JSON because it requires interop between multiple components, and JSON's tooling is very strong and ubiquitous. There's also value in how restrictive the data model is. While I want to use confy, I can't justify adding another serialization format (and all the tooling requirements and conversion ambiguity that come with it) to my project.

I see that YAML is already a config option. Is there desire for adding one for JSON? If so, I would be happy to take it on and make a PR following the same general structure as the YAML feature. I understand there are arguments against JSON as a configuration format however (lack of comments for example) and don't want to jump in adding it if the maintainers have no desire for the feature.

[matthiasbeyer]

Isn't JSON a valid subset of YAML? That'd mean that you can just use the YAML backend for your JSON files...

[badtuple]

Yes YAML's inline form is a superset of JSON, but that doesn't make it trivial to write JSON in YAML. I don't want to trust that the input is well formed, I want to error out if anything is ambiguous or malformed.

Some examples of where this might be a problem:

• {1: "something"} is valid YAML, but not valid JSON. It's very easy to leave quotes off the key, especially since many JSON parsers accept it. A good JSON parser would yell about 1 not being a string. The YAML parser may recognize that we are in the inline form and coerce it into a string ("1") or treat it as a number.
• YAML converts Yes into the boolean true, whereas a JSON parser would throw an error if someone forgot to quote the string "Yes".
• YAML coerces empty values into "null". So { "yolo": } and {"yolo":, "swag": 4} are both valid YAML that evaluate to {"yolo": null} and {"yolo": null, "swag": 4}. Forgetting to enter a value is incredibly easy to do.

Furthermore, there are many unofficial extensions to YAML that do things like import other files or allow running arbitrary code. Even if serde_yaml / confy doesn't do this, it means "valid" configs could work differently and have different meanings in different tools.

Rust's strong type system does provide decent resistance to many of these issues. But again, this project has a high degree of interop and it won't always be Rust reading it even if that's the only thing confy cares about.

Overall this probably seems very defensive. Technically if a person writes valid json and I parse it as YAML, it'll work in most scenarios. However, Hyrum's law and xkcd 1172 are not exaggerations. As soon as a config becomes valid (by people either figuring out that it's actually YAML and using it for convenience or preference, or by typo-ing their way in) then it will become very hard to change that behavior.

[CKingX]

Using JSON will also prevent ValueAfterTable TOML errors as well (and TOML Serde also states enums are not supported)