Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make iterator_proxy_value a forward_iterator (#4371) #4372

Open
wants to merge 5 commits into
base: develop
Choose a base branch
from

Conversation

captaincrutches
Copy link

@captaincrutches captaincrutches commented May 10, 2024

See #4371 for all the details - but long story short, there seems to be no reason not to expose iterator_proxy_value as a forward_iterator instead of just an input_iterator. This allows more use cases when items() is fed into C++20 std::views.

If there is a reason not to do so, please let me know - but the iterator_category on 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_category typedef entirely, and let iterator_traits deduce it - since the type otherwise satisfies ForwardIterator, 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.

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 to iterator_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.

@captaincrutches
Copy link
Author

Ahh - I see from the build logs that these jobs use astyle 3.1; when I ran make amalgamate, I installed astyle 3.4.

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.

Copy link

🔴 Amalgamation check failed! 🔴

The source code has not been amalgamated. @captaincrutches
Please read and follow the Contribution Guidelines.

@coveralls
Copy link

coveralls commented May 11, 2024

Coverage Status

coverage: 100.0%. remained the same
when pulling 104cdd8 on captaincrutches:cc-iterator
into 8c391e0 on nlohmann:develop.

@github-actions github-actions bot added S and removed L labels May 11, 2024
@captaincrutches
Copy link
Author

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.

@captaincrutches
Copy link
Author

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.

@nlohmann
Copy link
Owner

I'll check the Clang-Tidy warnings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants