result_and_scratch_storage/future design issues:

[MikeDvorskiy]

Actually, there are really result_and_scratch_storage/future design issues:

• result_and_scratch_storage type combines live-time extension of a temporary buffer and provides returning some result values from a kernel.
• Moreover result_and_scratch_storage type has limitation - only one type for return values and temporary values.
• result_and_scratch_storage allows to set more than one value return, but just the same type and there is not effective API in future object to get the all values, just the first.

Originally posted by @MikeDvorskiy in #1942 (comment)

[danhoeflinger]

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 be sure not to harm performance of the existing cases. I think that is possible but we need to be aware of it.

[danhoeflinger]

As mentioned here, 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 where M is a template integer argument to a function.

I would at least like to fix this and remove the specific functions which are only there to return a pair of std::size_t for 2022.9.0, if not complete our entire plan for refactoring __future, and __result_and_scratch_storage.

[danhoeflinger]

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 would be "nice to have" to allow differing types for return and temporary, it does limit potential performance, so it should be done with care. Certainly we can design it to give the most optimal performance for the types used though.