[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 use std::get here instead? Would not it be more readable?

[kboyarinov]

Suggested change

	apply_to_tuple_impl([](auto...){}, __f, __t, std::make_index_sequence<sizeof...(Views)>{});
	apply_to_tuple([](auto...){}, __f, __t);

[kboyarinov]

Suggested change

	static auto
	static decltype(auto)

[kboyarinov]

Suggested change

	constexpr zip_view(Views... views) : views_(views...) {}
	constexpr zip_view(Views... views) : views_(std::move(views)...) {}

[kboyarinov]

Does it makes sense to move functions to the apply_to_tuple_impl?

[kboyarinov]

Suggested change

	return it+=n;
	return it += n;

[kboyarinov]

Suggested change

	return it+=n;
	return it += n;

[kboyarinov]

Suggested change

	return it-=n;
	return it -= n;

[kboyarinov]

Please add a TODO comment or add a simple view constraint everywhere.