Hmm. I don't have an issue with this at all, but the more methods like this we gather, the more we should think about fixing it systemically by having the ability to index the fields or do multiple in one pass.

@jkeiser We do not have to merge this, we never got a request of this type... but I only implemented it as a precaution, and a proof of concept. We certainly do not have to merge it for release 1.0.

There would be other ways to handle this...

1. Build a single-pass matcher... like this...

auto [value1, value2, value3] = object.get("key1", "key2", "key3"); 

It would always fully scan the object, and might check for duplicates as it does so. That could possibly be quite performant.

2. Don't worry about duplicates but have the object iterator track the searched keys... as you encounter new keys, check whether you have had a request for them in the past... so... given... {"x":1, "x":2, "y":2}, you'd go...

auto x = object["x"];
auto y = object["y"]; // an error here would happen

Neither of these alternatives is super pleasant.

I could imagine the single-pass matcher working, especially if each of them returns a fork() so you could iterate them independently. I could also imagine some kind of object.get_map() which returns map<std::string_view, value> or whatever type a forked value is ...

I am happy to let this PR sit for a while longer.

I do not like this PR after all. Closing.