[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 (also check if it does move construction)
  • another zip_view
• 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.

[kboyarinov]

Does it makes sense to move functions to the apply_to_tuple_impl?

[MikeDvorskiy]

It seems I don't catch your question/suggestion..

[kboyarinov]

I mean modify to apply_to_tuple_impl(std::move(__tr), std::move(__f), __t, std::make_index_sequence)
Or we believe that these lambdas cannot capture a lot?

[MikeDvorskiy]

Now I see what you mean..
The implementation uses the lambdas with no capture at all or one integer variable. So, since it is an 'internal' code we may pass further these lambdas by copy w/o any overheads.