Dan Hoeflinger

> Are there any objections to me closing this PR? @akukanov @julianmi @danhoeflinger No objections here. I think your argument is sound. Its best if the we can rely on...

> There might be potential benefits of utilizing 32-bit addressing on other algorithms as well. I agree with this, but I also feel like this may be something to take...

So, this change has an consequence... [LegacyForwardIterator](https://en.cppreference.com/w/cpp/named_req/ForwardIterator) and therefore [LegacyBidirectionalIterator](https://en.cppreference.com/w/cpp/named_req/BidirectionalIterator) and [LegacyRandomAccessIterator](https://en.cppreference.com/w/cpp/named_req/RandomAccessIterator) requires default constructible. The way `transform_iterator` was written, it was returning `true` for `is_default_constructible` even when it was...

The clang format suggestion is a bug in clang format where it mistakes a binary AND for a rvalue reference. It is intentionally ignored.

Thanks all for the reviews! Very interesting investigation I think, and I like where it ended up.

I've split this into individual tests for each input sequence type (host_iter, sycl_iterator, usm_device, usm_shared, counting_iter). When grouped together, there is some potential for running out of memory during compilation...

> Could you rebase this branch with main, so we can ensure everything works well after the merge of PR #1445? I'm ready to approve after. Good point... done.

> I have tried to find out if the standard says anything about using parallel algorithms with `vector`. There is nothing directly said in this regard, and the only indirect...

@akukanov I've updated the PR to instead add to the input data page of the guide, with a note about `std::vector` (and remove it as a known limitation). Lets wait...

Why is this PR needed? These wrappers don't seem to add anything to the oneDPL function they wrap. Can the calling code just call oneDPL directly (or interchangeably, the std...