| commit | bdcec47f7f29ba5baef5037ab9139de2dabbc396 | [log] [tgz] |
|---|---|---|
| author | Michael Bolin <bolinfest@gmail.com> | Sat Jan 26 20:07:13 2019 |
| committer | Michael Bolin <bolinfest@gmail.com> | Sat Jan 26 20:07:13 2019 |
| tree | 48641e4b3531044aba396416c60c0e9c5c51a7be | |
| parent | f57a9232789326c8424395341f007e7a74b33a3a [diff] |
Tighten up support for trailing commas in array literals. The initial support for trailing commas in array literals had a bug when `deserialize_struct()` was used in conjunction with `#[serde(deny_unknown_fields)]`. I noticed this because there was a test case in `test_parse_enum_errors()` that I expected to fail (because it assumed trailing commas were disallowed), yet it was still passing (i.e., the trailing comma error was still being thrown). It appeared that when the number of fields to be deserialized was known, instead invoking `next_element_seed()` until it returned `Ok(None)`, serde would stop invoking it after it saw the last required field and move on to the `end_seq()` call. Before this change, `end_seq()` would fail because the `SeqAccess` would not have consumed the final trailing comma. This changes the implementation of `SeqAccess` so that it is responsible for consuming the comma associated with a value before returning the value. Overall, I think this implementation of `SeqAccess::next_element_seed()` is cleaner than the original.
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.