David Tolnay

Same here, even a little slower. It may be that unaligned u8x16 loads are slow - you don't have [this part](https://github.com/miloyip/rapidjson/blob/369de87e5d7da05786731a712f25ab9b46c4b0ce/include/rapidjson/reader.h#L917-L925) that establishes 16-byte alignment. That would also serve to...

I am talking about alignment of `$parser.source[$parser.index]`. If that is not 16-byte aligned, there is nothing the SIMD library can do about it.

Yes. And then for the other test, that many bytes + 16 more.

It's actually `"result": null`, not `"null"`. [*Playground*](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=78fc69949f56ac611bd2c3f8a4c5cdb9) Untagged means that the serialized data does not identify which variant it represents via some name / tag. `"result": "invalid"` does identify a...

Sounds good. Where in the docs would you expect to find this information?

Seems reasonable. Would these return Option and just destroy your value if it is the wrong type?

I think I would slightly prefer the Result way. There are at least 3 reasonable error types: - `Result`—just give them back the value. I would prefer not to do...

Seems reasonable. To clarify - you mean specifically the `serde_json::Error` type and not `std::error::Error` types in general, right?

That would tend to give you a pretty verbose representation like: ```json { "Syntax": [ { "MissingField": "f" }, 10, 20 ] } ``` I think we should instead implement...

Can you explain the use case where you need the structured representation? As far as I could tell from some GitHub searches, nobody is currently pattern-matching on our error type...