| commit | ca5782632fc8dc3f9cf2f22055b87f910cad761f | [log] [tgz] |
|---|---|---|
| author | Adrian Taylor <adetaylor@chromium.org> | Thu Dec 16 06:44:19 2021 |
| committer | Adrian Taylor <adetaylor@chromium.org> | Thu Dec 16 15:57:12 2021 |
| tree | 3de7b49e30d6f33915bf7526b5a0c83f3f92b74c | |
| parent | a12f58435a7d80c3e288c11bcbd737e5455076b4 [diff] |
Make comment support switchable Previously, serde_jsonrc always accepted embedded comments in the JSON. With this change, this is now switchable. Bug: 1069271 Change-Id: I27c19c63bcebfc6cb492f2ee9874e0d9a38fb686
This is a lenient JSON parser forked from the serde_json crate that is that is designed to parse JSON written by humans (e.g., JSON config files). This means that it supports:
/* and // style comments.\v and \xDD literal escapes (for vertical tab and two-digit hexadecimal characters)I am still playing with the idea of making it more lenient, which could include taking more features from the JSON5 spec.
When I created this crate, my immediate goal was to create a fast parser for a config file for a work project. I wanted a file format that would be familiar to developers, but restrictive in what it accepted. I had encountered this problem several times in my career, which always faced the same set of tradeoffs:
When considering the relative downsides of each of these options, it was clear that what I really wanted was a more lenient JSON. The next question was how to get a lenient JSON parser (in Rust, in my case). I considered the following options:
This was my first choice, but the maintainer wanted to keep the scope of serde_json limited to strict JSON, so we respectfully agreed that forking was the way to go.
The json5 crate supports the superset of JSON specified at https://json5.org/. In principle, the feature set met my needs, but in practice, I discovered the implementation was not nearly as performant as serde_json, even for small files. (Also, it cannot parse streams: only strings.)
The serde-hjson crate provies a parser for a different superset of JSON named Hjson (“JSON for humans”). I am not a fan of Hjson because the language it accepts is not valid JavaScript, so it's not nearly intuitive as JSON.
Ultimately, I would like to see a more lenient form of JSON standardized that experiences the same level of ubiquity as JSON today. I would like this crate to be a reference implementation of that new, more lenient specification.
I suspect that being more conservative in adding new features to the spec has the best chance of getting widespread buy-in, which is why I am not immediately gravitating towards implementing all of JSON5. Instead, I am starting with my suggested improvements to JSON from way back in 2011.
Finally, my gut feeling is that a new version of JSON should still be valid JavaScript. For example, one other shortcoming of JSON today is a lack of support for multiline strings. JSON5 addresses this by allowing \ for continued lines, but at this point, I think backtick (`) would be a more intuitive solution because that would be consistent with ES6 (though string interpolation would not be supported).
Because serde_jsonrc is a fork of serde_json, it maintains the original licence, which means it is licensed under either of
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in serde_jsonrc by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.