Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Add an option to allow C99-like comments. #514

Closed

Conversation

bolinfest
Copy link

@bolinfest bolinfest commented Jan 24, 2019

This would introduce a serde_json::Options type that could be
passed to from_str, from_bytes, or from_reader. Initially,
the only option would be allow_comments, though I would also
like to add support for allow_trailing_commas going forward.

I read through #168 and
saw that this was rejected in the past, but I was curious if we
could revisit this issue. The suggestion on the issue was to use
Hjson, which I think is
"too loose" for most peoples' taste. Also it has not been updated to
target serde 1.0.x yet
.

Allowing C99-like comments and trailing commas results in an input
language that is still valid ECMAScript (it's just version 5.1 instead
of 3), which cannot be said for things like Hjson. Because it is
familiar to JavaScript developers, I have seen it used as an input
language in a number of domains. For example, all settings files in VS
Code appear to allow this: it even has a special language mode to
recognize this named "JSON with Comments (jsonc)."

It is fairly common for JSON parsers to allow options like this.
For example, here is the full set of options supported by Folly's
(C++ library) JSON parser:

https://github.com/facebook/folly/blob/74ea53886c3333eda4eaf457d538a678ceaa5add/folly/json.h#L56-L72

Google's Gson parser has a setLenient() option:

https://github.com/google/gson/blob/9d44cbc19a73b45971c4ecb33c8d34d673afa210/gson/src/main/java/com/google/gson/stream/JsonReader.java#L296-L324

There's also https://json5.org/, which tries to formalize the leniency.

If serde_json is not on board with this direction, I guess I should
fork this repo and create serde_jsonc or serde_lenient_json? I would
prefer not to do that, but if you want to keep serde_json so that it
only supports RFC 8259 or whatever it is, then I suppose forking is the
best way forward.

One final note: although #168
notes that comments were "explicitly excluded from JSON," it doesn't
mean it was the right choice. I've been arguing against it for years
now: http://bolinfest.com/essays/json.html.

This would introduce a `serde_json::Options` type that could be
passed to `from_str`, `from_bytes, or `from_reader`. Initially,
the only option would be `allow_comments`, though I would also
like to add support for `allow_trailing_commas` going forward.

I read through serde-rs#168 and
saw that this was rejected in the past, but I was curious if we
could revisit this issue. The suggestion on the issue was to use
[Hjson](https://github.com/hjson/hjson-rust), which I think is
"too loose" for most peoples' taste. Also it has [not been updated to
target serde 1.0.x yet](hjson/hjson-rust#6).

Allowing C99-like comments and trailing commas results in an input
language that is still valid ECMAScript (it's just version 5.1 instead
of 3), which cannot be said for things like Hjson. Because it is
familiar to JavaScript developers, I have seen it used as an input
language in a number of domains. For example, all settings files in VS
Code appear to allow this: it even has a special language mode to
recognize this named "JSON with Comments (jsonc)."

It is fairly common for JSON parsers to allow options like this.
For example, here is the full set of options supported by Folly's
(C++ library) JSON parser:

https://github.com/facebook/folly/blob/74ea53886c3333eda4eaf457d538a678ceaa5add/folly/json.h#L56-L72

Google's Gson parser has a `setLenient()` option:

https://github.com/google/gson/blob/9d44cbc19a73b45971c4ecb33c8d34d673afa210/gson/src/main/java/com/google/gson/stream/JsonReader.java#L296-L324

There's also https://json5.org/, which tries to formalize the leniency.

If `serde_json` is not on board with this direction, I guess I should
fork this repo and create `serde_jsonc` or `serde_lenient_json`? I would
prefer not to do that, but if you want to keep `serde_json` so that it
only supports RFC 8259 or whatever it is, then I suppose forking is the
best way forward.

One final note: although serde-rs#168
notes that comments were "explicitly excluded from JSON," it doesn't
mean it was the right choice. I've been arguing against it for years
now: http://bolinfest.com/essays/json.html.
@bolinfest
Copy link
Author

Also, I know the actual code needs more comments and tests. For now, I just wanted to get enough code written to motivate the discussion. It's nice that it appears the support for this feature can be encapsulated within the parse_whitespace() function.

@dtolnay
Copy link
Member

dtolnay commented Jan 24, 2019

Thanks! I would prefer for this to live in a different crate. I filed dtolnay/request-for-implementation#24 to follow up.

@dtolnay dtolnay closed this Jan 24, 2019
@serde-rs serde-rs locked and limited conversation to collaborators Mar 7, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants