|author||bolinfest <email@example.com>||Tue Feb 18 00:26:51 2020|
|committer||GitHub <firstname.lastname@example.org>||Tue Feb 18 00:26:51 2020|
Merge pull request #3 from adetaylor/merge-serde-json-1.0.45 Merge upstream serde_json 1.0.45
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:
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.)
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.
\ 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.