[oneDPL][rfc][ranges][L1] the third portion of the range based API

[MikeDvorskiy]

[oneDPL][rfc][ranges][L1] the third portion of the range based API

[Copilot]

Pull Request Overview

This PR introduces an RFC for the third portion of oneDPL range-based APIs, focusing on implementing additional parallel algorithms based on usage statistics from GitHub C++ code analysis. The proposal outlines the implementation approach, requirements, and testing strategy for these new range-based algorithm variants.

• Proposes 14 new range-based algorithms including set operations, memory algorithms, and mutating algorithms
• Establishes implementation requirements based on P3179 and P3709 proposals with support for all oneDPL execution policies
• Defines comprehensive testing coverage requirements and implementation limitations for device policies

[danhoeflinger]

One optional wording change, but LGTM.
Largely this is similar to previous RFCs.

I wonder if it makes sense to extract some shared language between these in an umbrella RFC and have individual pieces reference that. Not sure if its worth the effort.

[danhoeflinger]

reapproving

[dmitriy-sobolev]

reapproving

@danhoeflinger, sorry for dismissing your approval. I've added one more correction. I do not plan adding more.

• The memory algorithms should be tested with std::ranges::subrange and std::span,
  adapters which can be used with manually allocated and managed storage.

That's because in order to test the memory algorithms, you need to manually manage memory. The views removed, such as std::views::all (already expects a range/container e.g. std::vector with automatic memory management), std::views::iota (does not point to underlying memory) and others are not suitable.

[danhoeflinger]

will reapprove if you apply my nitpick.