oneapi-src
Change zip_iterator to always use oneDPL's tuple
zip_iterator had some mixed use of std::tuple and oneDPL's internal tuple internally. Specifically we use of std::make_tuple in the constructor for zip_iterator we currently use the constructors from std::tuple on input types for zip_iterator, then use implicit conversion to our internal tuple type. We also use the internal tuple type for reference and value_type, but use std::tuple for pointer. It makes sense to standardize what we use internally for zip_iterator to be oneDPL's tuple.
Details:
This was originally motivated by an error when we have a zip_iterator of two iterators where one is a transform_iterator<it, lambda>. Due to the way transfom_iterator is written, this results in a build error for some std library implementations when calling std::make_tuple. It turns out that a more direct fix is #1445 (look there for more details). I still believe this PR is a good change, however it may not outweigh the momentum of keeping the code the same.
After some investigation of the original error, it seems that this PR is more an "avoidance" of an error than a direct fix (#1445 is more direct).
Also, I have reverted the changes to zip_forward_iterator as it is used only on the host and has no need for a trivially copyable tuple.
I still believe what remains in this PR is an improvement to the code, and outweighs the risk.
After a discussion offline with @rarutyun , it was decided to not go forward with this patch unless we find a specific use case we are fixing. Technically, this changes the public API, as it changes the pointer typedef.
The other change with the make_tuple does not change the public API, but it does change code without something clear we are fixing. It may save a few copies, but has no clear other benefit.
These seem like good changes if we were writing from scratch, but this must be weighed against the risk of changing code we don't know to be broken.
To pick this PR back up, we will want to examine in more detail and try to find some use cases for which these changes would fix or improve things which are broken.