David Tolnay

This would be a good candidate for https://github.com/serde-rs/serde/issues/553.

```diff - a: Option, + a: Option, ``` https://github.com/serde-rs/serde/issues/984#issuecomment-314143738 is already generic to work on any type. The code uses `Option` so that the three cases are represented by `None`,...

```rust type S = serde_json::Value; ``` For a `Value` you can already tell whether some key is absent, present but null, or present and non-null so you don't need anything...

One possible way to expose this would be relaxing the bound on serde_json::from_reader to accept some sealed trait that is implemented for all io::Read as well as for an adapter...

My feeling is that the use case of not being able to handle an io::Error is not common enough to deserve a top-level `serde_json::from_reader_eager` function. I would prefer to come...

@messense @SergioBenitez to unblock things for Rocket I published [`from_reader_eager`](https://docs.rs/eager_json/0.1.0/eager_json/fn.from_reader_eager.html) in a separate crate. Once we figure out the right API on the serde_json side we can update that implementation...

Yes that should be fine.

Yes you could wrap the JSON deserializer so that it does not do any unescaping. Something like: ```rust // [dependencies] // serde = "1.0" // serde_json = { version =...

I don't think you have accurately characterized the assumptions around utf8 in Serde: > it also trusts the `Display` trait implementation on an arbitrary input object to correctly report the...

Thanks for the feedback @Shnatsel. I would love to get to the root of where our perspective differs. In response to your observations: > in order to verify that this...