[oneDPL] Add more copying mutating parallel range algorithms

[dmitriy-sobolev]

Adding reverse_copy and unique_copy parallel range algorithms into oneDPL specification.

[dmitriy-sobolev]

@akukanov and @MikeDvorskiy, could you take a look at that addition? It may make sense to add it to be consistent with other algorithms using aliases with <algorithm>_result semantics.

Alternatively, we could just use std::ranges::in_in_out_result.

[akukanov]

++ @rarutyun

Even though it is only an alias, I am not sure if adding it as a public name in the oneDPL namespace is a good idea, given that the same alias will be added into C++26.

I incline towards either making it exposition-only name, like the projected value type, of just using in_in_out_result.

[dmitriy-sobolev]

4df673d switches to using a plain std::ranges::in_in_out_result.

[rarutyun]

@dmitriy-sobolev, @akukanov, my first reaction is it's better to keep in_in_out_result because it's better to have one name meaning one thing (if possible). For some weird scenarios where users try using namespace oneapi::dpl; this alias may conflict with std:: alias while the refer to the same type (check this out).

Maybe we should add a comment (if not already) that in_in_out_result is exactly what reverse_copy_truncated_result aliases since C++26, so we don't see the reason to introduce our own aliases

[dmitriy-sobolev]

Thanks for the confirmation.

Maybe we should add a comment (if not already) that in_in_out_result is exactly what reverse_copy_truncated_result aliases since C++26

This part is done.

... so we don't see the reason to introduce our own aliases

I suppose this additional clarification should be added into the implementation.

[akukanov]

Depending on what should be considered as the "base" C++ standard, this wording might be inaccurate. As of now, the rest of the list compares with C++20/23. The new alias for the truncated result of parallel reverse_copy will only appear in C++26.

[dmitriy-sobolev]

I've updated that note in a8842c6 adding more details.

[danhoeflinger]

LGTM

[dmitriy-sobolev]

@danhoeflinger, sorry for dismissing your approval.

I've made a correction. Now, reverse_copy interface is compared against the standard serial one, not the parallel API from the draft. It's aligned with all other algorithms in this document.

[danhoeflinger]

reapproving