Dan Hoeflinger

This issue was added when we added `#include ` (or its predecessor) in to `test_config.h` (which was merged *after* #1250) from this comment: https://github.com/oneapi-src/oneDPL/pull/1548#pullrequestreview-2040992372. Currently, all of these header inclusion...

> Other than my comments, looks good to me. I would also ask somebody to review the infrastructure part. I've reviewed the infrastructure part, and it LGTM. I've reviewed the...

I agree that there are issues which need to be addressed here. However, if we want to expand its functionality to be suitable to more cases, we just need to...

As mentioned [here](https://github.com/uxlfoundation/oneDPL/pull/1942/files#r1929922356), I think we can use `result_and_scratch_storage` return array to implement returning multiple elements from `__future` with a generic function which will return a tuple of size `M`...

I do think the second point: >Moreover result_and_scratch_storage type has limitation - only one type for return values and temporary values. Needs to be treated with care though, while this...

It seems like we also need a fix for the oneDPL specification as well: https://github.com/uxlfoundation/oneAPI-spec/blob/71f6bf676ca0b5d258373d499403f8738298e648/source/elements/oneDPL/source/parallel_api/parallel_range_api.rst?plain=1#L314 As for how to deal with any deprecation, or removal since it has already been...

> In regard to "keep device copyable traits specialization with the functor itself". We discussed it (with Alexey or Ruslan) and tented to conclusion that it is worse comparing with...

It seems there is an issue with same mangled name for a kernel. I will see if it is something with the test, or with oneDPL...

I will open a RFC. No, it will not fit into existing patterns efficiently, but I have a tentative plan, so an RFC seems correct here.

https://github.com/oneapi-src/oneDPL/pull/1930 I've added an RFC for discussion.