John Keiser

> How do we handle SAX or SAX-like parsing? Do you consider that "API" or "internals"? Honestly, it could go into both camps. SAX will definitely have an API :)...

Even the linked benchmark checks floating point accuracy, so it's probably a good use of time (and supporting a contributor is a good use of time even if it's not...

It seems like this might also play nicely with multi-field lookup interface ("find field x, y or z, whatever comes next").

What even is that I've never seen enums in C++ do that much stuff

Yeah, even just renaming it to that might be best. Or an error struct that has things like `.is_json_error()` `.is_system_error()` `.is_usage_error()`?

T_ATOM_ERROR, F_ATOM_ERROR, etc. are also probably too granular if we're designing it. Ideally we'd have a small number of error categories you check in your code, but a large number...

True. I think it still has value to On Demand ... and it might be easier to prove out in DOM, where more things are held constant.

I actually wonder if doing this would be faster than haswell and westmere, too . The frontend already repeats a lot of the work of going through numbers and strings....

It definitely seems likely. Ultimately I'd like to see an interchangeable api where you can use json path to find objects, declarative deserialization to get individual records, and drop back...

This is also a nice way to make efficient order insensitive object deserialization. It can even use hashes when it finds the object out of order.