RFC for zip_view implementation, for oneDPL C++20

[MikeDvorskiy]

The proposal to implement zip_view in oneDPL. A part of the general RFC discussion #1944 about implementing useful C++23 views.

[dmitriy-sobolev]

There is one question regarding the conversions of the iterators. The rest are minor stylistic and wording corrections.

[Copilot]

Pull request overview

This RFC proposes implementing zip_view for oneDPL's C++20 range APIs, providing functionality equivalent to C++23's std::ranges::zip_view but with device copyability support and compatibility for C++20 users.

Changes:

• Introduces RFC documentation for oneapi::dpl::ranges::zip_view implementation
• Defines key requirements including C++20 compatibility, API compliance with C++23 standard, and device copyability
• Proposes using oneapi::dpl::__internal::tuple instead of std::tuple to address technical limitations and ensure device copyability

Comments suppressed due to low confidence (3)

rfcs/proposed/zip_view/README.md:1

• Corrected spelling of 'Considiration' to 'Consideration'.

# zip_view Support for the oneDPL Range APIs with C++20

rfcs/proposed/zip_view/README.md:1

• Grammar error: 'another' should be 'other' when used with plural noun 'issues'.

# zip_view Support for the oneDPL Range APIs with C++20

rfcs/proposed/zip_view/README.md:1

• Grammar error: Use 'an' instead of 'a' before words starting with a vowel sound. Should be 'an indirectly writable requirement'.

# zip_view Support for the oneDPL Range APIs with C++20

---

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

[danhoeflinger]

@copilot can you fix the spelling error you identified as low confidence comment?

rfcs/proposed/zip_view/README.md:1

Corrected spelling of 'Considiration' to 'Consideration'.

[danhoeflinger]

LGTM

[akukanov]

The key problem that still needs to be addressed is the choice of the namespace.

We should not place the new API into oneapi::dpl::ranges before updating the specification. At the same time, we already have oneapi::dpl::experimental::ranges::zip_view. We can change the implementation of the latter (perhaps only for C++20 and higher) - but then we need to be sure that that implementation also works with other experimental views and range algorithms. We can use another namespace within oneapi::dpl - if there is a good idea how to name it. We can change the API name to include some indication that it is not yet fully supported, but we probably do not want to. Are there other options to consider?

[MikeDvorskiy]

The key problem that still needs to be addressed is the choice of the namespace.

We should not place the new API into oneapi::dpl::ranges before updating the specification. At the same time, we already have oneapi::dpl::experimental::ranges::zip_view. We can change the implementation of the latter (perhaps only for C++20 and higher) - but then we need to be sure that that implementation also works with other experimental views and range algorithms. We can use another namespace within oneapi::dpl - if there is a good idea how to name it. We can change the API name to include some indication that it is not yet fully supported, but we probably do not want to. Are there other options to consider?

oneapi::dpl::experimental::ranges::zip_view
oneapi::dpl::experimental::ranges::views::zip
oneapi::dpl::experimental::views::zip

[danhoeflinger]

LGTM with namespace changes

[akukanov]

Approved after making some cosmetic changes and adding a paragraph about the experimental stage.

When the RFC is moved to the experimental status, productization conditions (aka "exit criteria") will need to be described.

[danhoeflinger]

LGTM with the changes