commit | d2f7ef04b0746ae0b0b16155eea3b40eab4387f5 | [log] [tgz] |
---|---|---|
author | Adrian Taylor <adetaylor@chromium.org> | Thu Apr 16 18:32:21 2020 |
committer | Adrian Taylor <adetaylor@chromium.org> | Thu Apr 16 18:34:37 2020 |
tree | 56c3bd511b1121af17affc39be9b1f9d31f66728 | |
parent | 4b6d8478586db4b8040a90c01f501566a23a8609 [diff] |
Adding new tests
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.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.