John Keiser

Moving to 1.0, but please feel free to move back in if this is something you're super planning to get done short term!

I've been noodling on this too :) But I haven't got as far as you; this sounds super promising. > if you need to take a SIMD register, and just...

Yes! One alternate way to make the API could be: ```c++ object.get_fields({ { "name", [&](auto name) { ... } }, { "id", [&](auto id) { ... } }, { "content",...

The On Demand interface (see the readme, we'll be switching to it as the primary api soon) doesn't store object keys at all, and instead simply compares your string bytes...

> is there an option to set the start index when using on demand so it searches less bytes ? Not sure what you mean--could you put up a concrete...

I was wondering if there was a way we could use initializer lists and have c++ 11 compatibility, too.

If there are c++ reasons to use pair, I'm game. The reason is indeed as @lemire suggests: I wanted to be able to type key and value. Also, I am...

I see the value in supporting this scenario--there surely will be plenty of C++ code already designed to work with pairs. What if key_value_pair looked like this? ```c++ class key_value_pair...

On Demand takes this exact approach for fields: https://github.com/simdjson/simdjson/blob/master/include/simdjson/generic/ondemand/field.h#L14 Deprecation of key / value for dom is going to be hard. We ok with a hard break if we do...

IMO, we should drop this one from 1.0 given it's (at least theoretically) in better shape for On Demand and we're definitely headed towards that as primary API. Feel free...