[oneDPL][ranges] + zip_view implementation for C++20

[MikeDvorskiy]

[oneDPL][ranges] + zip_view implementation for C++20. The implementation and test.

• namespace: oneapi::dpl::ranges
• based on oneDPL device copyable tuple

[dmitriy-sobolev]

Let me leave just a couple of minor comments. I am going to look at the whole PR during this week.

[dmitriy-sobolev]

What do you think about testing the following properties of zip_view/zip?

• begin/end (they should also probably be checked if they are iterators)
• cbegin/cend
• front/back
• size
• empty
• operator bool
• construction:
  • ranges::zip(...)/ranges::zip_view(...)
  • empty view (views::zip())
  • another view (*move construction is not checked)
  • another zip_view
• ranges::zip(...) is a customization point object

I assume that the functionality must match what is required from c++ standard looking at the description. That's why I suggest testing all these properties. Let me know if the implementation is expected to be more relaxed (and how if it is).

[dmitriy-sobolev]

The description says:

... based on oneDPL device copyable tuple

According to SYCL 2020, std::tuple is also device copyable (if the wrapped types are also device copyable, of course). Does it make sense to use std::tuple instead of the internal one?

[danhoeflinger]

The description says:

... based on oneDPL device copyable tuple

According to SYCL 2020, std::tuple is also device copyable (if the wrapped types are also device copyable, of course). Does it make sense to use std::tuple instead of the internal one?

The advantage here of using oneDPL's tuple is that it is trivially copyable (for trivially copyable types) which means that any class or structure which uses oneDPL's tuple can be implicitly device copyable rather than requiring a specialization of sycl::is_device_copyable (because of the tuple). std::tuple isn't specified to be trivially copyable.

The advantage is not just to avoid extra code here but also to not impose requirements on users to provide these specializations for types which are composed of a zip_view as well.

There can be downsides to using oneDPLs tuple in that it may not be as fully featured as std::tuple in some ways but I think this is the better option.

[MikeDvorskiy]

to use std::tuple instead of the internal one?

Actually, before C++23 standard library there is a problem with std::tuple swap ability. It is bigger issue that doesn't allow to use std::tuple for zip_view implementation for oneDPL C++20.

[MikeDvorskiy]

regarding > * cbegin + cend
cppreference:

cbegin
  
(C++23)
 
returns a constant iterator to the beginning of the range.
(public member function of std::ranges::view_interface<D>)
cend
  
(C++23)
 
returns a sentinel for the constant iterator of the range.
(public member function of std::ranges::view_interface<D>)

[kboyarinov]

Why cannot we use x.current <=> y.current? Spaceship operator is undefined for some of our internal iterator types or it is undefined for internal tuple?

[MikeDvorskiy]

yes, spaceship operator is undefined for x.current_...

[danhoeflinger]

When adding comparison between internal tuples, we looked at adding spaceship and it was deemed not worth the effort at the time. We could use this as motivation for adding it, but it would require a bit of work. We would need to trigger it off of __cpp_lib_three_way_comparison >= 201907L, and in that case replace the existing comparison operators with the spaceship, to time it properly with std::tuple <=> operator

#1472 (comment)

[danhoeflinger]

The thought was that it wasn't worth the maintenance because we would need to implement both to support our full support matrix, and it would be only helpful for those explicitly calling <=> on the internal tuple (which is what we might want to do here as I understand it).

[dmitriy-sobolev]

Our testing framework is not adapted for assert: it defines NDEBUG during release test builds. We should either avoid that definition, or do not rely on assert in the tests.

[MikeDvorskiy]

1. In spite of that we are using assert in our tests more then 10 files... It seems an issue should be created.
2. I know that a better way to use our own macro like EXPECT_TRUE f.e.

[dmitriy-sobolev]

1. I will create it.
2. That sounds good. Could you do it? I see that there is still one assert in the test.

[dmitriy-sobolev]

1. I will create it.

Done: #1945.

[dmitriy-sobolev]

The result is also should be checked. Would not it be better to use existing test_range_algo utility?

[MikeDvorskiy]

It is a serial std::ranges::for_each. We believe that std::ranges::for_each works fine. So, we are checking just compilation with zip_view here.

[dmitriy-sobolev]

Even if the algorithm is proven to work well, something can theoretically be wrong with the zip_view implementation, which would result in incorrect run-time behavior, e.g. wrong begin() or end() implementation. I am still inclined it would be viable to check the result.

Perhaps, it is also makes sense to check if the operation applies only to the projected value.

[dmitriy-sobolev]

I would also expect checking the second sequence, e.g. to test if the zipped elements are moved together.

[dmitriy-sobolev]

Should zip also be checked for availability in oneapi::dpl::views namespace?

[dmitriy-sobolev]

regarding > * cbegin + cend cppreference:

cbegin
  
(C++23)
 
returns a constant iterator to the beginning of the range.
(public member function of std::ranges::view_interface<D>)
cend
  
(C++23)
 
returns a sentinel for the constant iterator of the range.
(public member function of std::ranges::view_interface<D>)

zip_view is based on view_iterface, and the later does not have cbegin/cend in c++20. That means our c++20 zip_view will not have cbegin/cend, and we are not going to provide them. Is that correct understanding?

[kboyarinov]

Did not we think about having oneapi::dpl::zip_view as part of namespace std::ranges prior to C++23?
It will allow the user to have portable code for each version of the standard. Otherwise, we will need to think about aligning oneapi::dpl::zip_view with the C++23 and later as well.