zip_view: make equality operator member function, not hidden friend

[danhoeflinger]

Convert the zip_view iterator-sentinel operator== from a hidden friend to a member function to fix a compilation error on GCC. As a hidden friend, the operator lacked access to sentinel's private __get_end() method because friend functions don't inherit the access rights of their enclosing class. Making it a member function resolves this portably, as member functions of a nested class inherit the enclosing class's friendships. This also removes the existing MSVC workaround that made __get_end() public on that compiler for the same reason.

Pending CI test run.

Update: CI run looks good for the operator== changes. It may be good to think about this a little more though, and CI for operator- and coverage changes is still pending.

[Copilot]

Pull request overview

This PR updates zip_view’s iterator/sentinel comparison implementation to fix a GCC compilation error by moving the iterator–sentinel operator== from a hidden friend to an iterator member function, and removes the prior MSVC-only access workaround on the sentinel.

Changes:

• Convert zip_view::iterator’s iterator–sentinel operator== from a hidden friend to a member function.
• Remove the _MSC_VER-gated public: workaround that previously exposed sentinel::__get_end().

Comments suppressed due to low confidence (1)

include/oneapi/dpl/pstl/zip_view_impl.h:433

• sentinel::__get_end() is now unconditionally private, but iterator still declares a hidden-friend operator-(const iterator&, const sentinel&) that calls __y.__get_end(). That free function won’t inherit zip_view’s friendship, so this will still be a hard compile error (and will be instantiated by the existing zip_view.minus tests). Consider applying the same fix as operator==: make the iterator–sentinel operator- a iterator member (or otherwise grant it access via an explicit friend declaration) so it can legally call sentinel::__get_end().

        friend class zip_view;

        decltype(auto)
        __get_end() const
        {
            return __end;

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

This PR adjusts zip_view’s iterator–sentinel equality to be a member function (instead of a hidden friend) to ensure it can access the sentinel’s private __get_end() and compile correctly on GCC.

Changes:

• Convert zip_view::iterator’s iterator–sentinel operator== from a hidden friend to a const member function.
• Remove the MSVC-specific workaround that temporarily exposed sentinel::__get_end() as public.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

This PR updates zip_view’s iterator/sentinel comparisons to avoid a GCC access-control compilation issue by moving operator== (and iterator - sentinel) from hidden friends to iterator member functions, leveraging the enclosing class friendship to access sentinel::__get_end(). It also adds targeted tests to exercise iterator/sentinel equality and subtraction in non-common-range scenarios.

Changes:

• Convert zip_view::iterator == sentinel from a hidden friend to an iterator member operator==.
• Convert zip_view::iterator - sentinel from a hidden friend to an iterator member operator-, keeping sentinel - iterator as a delegating hidden friend.
• Add regression tests covering iterator/sentinel ==, !=, and - with unbounded and forward-only + sized-sentinel ranges.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
include/oneapi/dpl/pstl/zip_view_impl.h	Moves iterator/sentinel operator== and operator- to iterator members and removes the MSVC-only public __get_end() workaround.
test/parallel_api/ranges/zip_view.pass.cpp	Adds new C++20 ranges tests to validate iterator/sentinel equality and sized-sentinel subtraction behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[danhoeflinger]

@MikeDvorskiy @kboyarinov I do still think this is the better version of our previous workaround, and is worth considering.

[kboyarinov]

LGTM

[danhoeflinger]

@MikeDvorskiy What do you think of this?