Make iterator_proxy_value a forward_iterator (#4371)#4372
Make iterator_proxy_value a forward_iterator (#4371)#4372nlohmann merged 3 commits intonlohmann:developfrom captaincrutches:cc-iterator
Conversation
|
Ahh - I see from the build logs that these jobs use astyle 3.1; when I ran Re-running with the matching version of astyle produces much saner results :) Though it still does remove a bunch of blank lines in the single-include headers. |
🔴 Amalgamation check failed! 🔴The source code has not been amalgamated. @captaincrutches |
|
Okay, I reset the single-include files entirely and tried again, and now we've got a diff that actually looks correct. Sorry for the noise! I'm happy to rebase and clean up these extra bad commits if that would be preferable. |
|
Clang-tidy failures look unrelated to my change - looks like #4311 already exists trying to fix them. I'm not sure what to make of the xcode 12.4 build - seems like something stalled out and hit a timeout, but I can't tell what... the rest of the build looks like it was going fine up until it stopped in its tracks. |
|
I'll check the Clang-Tidy warnings. |
|
Updated now that CI is fixed, to pick up those changes. Also squashed down all the amalgamate weirdness from before. |
|
Clang-tidy failure looks like a Looks like there's already a case of this warning that's suppressed by the recent CI-fixing change, I assume because On the other hand, this one looks like it's operating on a json object, which does have I'll defer to you guys here, since it seems a bit of a hot topic: should I fix the warning, or suppress it for now? |
|
Please add a NOLINT comment. |
|
Thanks a lot! |
…n#4372) * Make iteration_proxy_value model forward_iterator * Amalgamate * Suppress tidy warning
…teration_proxy The iteration_proxy in nlohmann_json is now a std::forward_iterator instead of an std::input_iterator, enabling broader compatibility with C++20 std::views. Refs: nlohmann/json#4371, nlohmann/json#4372
See #4371 for all the details - but long story short, there seems to be no reason not to expose
iterator_proxy_valueas aforward_iteratorinstead of just aninput_iterator. This allows more use cases whenitems()is fed into C++20std::views.If there is a reason not to do so, please let me know - but the
iterator_categoryon this type currently seems to long predate the more recent change to fix it for C++20 ranges initially. As well, the actual json iterator which the proxy wraps is also a forward iterator, so this keeps them on par with each other in terms of capabilities.Another option is to remove this
iterator_categorytypedef entirely, and letiterator_traitsdeduce it - since the type otherwise satisfiesForwardIterator, it should (and does, in my motivating case) do the right thing. But since the other required typedefs are here, might as well keep it but change it IMO.I'm not sure what, if any, tests can/should be updated/added in this case - I'm open to suggestions, though it seems like all the relevant
static_asserts and such should still apply.Pull request checklist
Read the Contribution Guidelines for detailed information.
include/nlohmanndirectory, runmake amalgamateto create the single-header filessingle_include/nlohmann/json.hppandsingle_include/nlohmann/json_fwd.hpp. The whole process is described here.Note on amalgamation: I did run
make amalgamate, and that touched a bunch of lines unrelated to my change. The actual change I've made is toiterator_proxy.hpp, and hopefully hiding whitespace in the diff will narrow that down. If you'd rather I revert the other amalgamate changes to keep this diff confined to the 2 (well, 4, including generated code) lines I changed, I'm more than happy to do so - but I figured I'd err on the side of caution w.r.t. any checks that run in CI.