Move sycl::event and __result_and_scratch_storage into __future

[SergeyKopienko]

In this PR we move the instances of sycl::event and __result_and_scratch_storage into __future constructor to avoid extra operations with counters inside std::shared_ptr objects which are the members of __result_and_scratch_storage (and probably in sycl::event implementation too).

Also we avoid copy operation for _ExecutionPolicy instance inside __result_and_scratch_storage too.

Please take a look to https://stackoverflow.com/questions/41871115/why-would-i-stdmove-an-stdshared-ptr for details.

Additionally, in this PR we fix issue #1776 : we remove ability to create __future instance by copy and copy-assignment:

    using FutureType = __future<_Event, _Args...>;
    // ....
    __future(const FutureType&) = delete;
    __future(FutureType&&) = default;

    FutureType&
    operator=(const FutureType&) = delete;
    FutureType&
    operator=(FutureType&&) = default;

[danhoeflinger]

For this to stop the copy from happening, changes are required for __future as well I believe. I think @julianmi may be working on this already, we have discussed it a little.

Here is a godbolt that shows that even with this move, it still ends up with a copy when creating the tuple, unless we forward it in. The downside to such a change is it requires explicit specification of the __future type, rather than allowing it to use deduction. Julian has been looking at a way to at least allow the user to skip specifying the event type, but I don't think we can avoid requiring users to define the future value types. In the end, this may not be a bad thing, as it requires users of __future to be more deliberate with their types.

https://godbolt.org/z/vEWz6svMT

[julianmi]

For this to stop the copy from happening, changes are required for __future as well I believe. I think @julianmi may be working on this already, we have discussed it a little.

Here is a godbolt that shows that even with this move, it still ends up with a copy when creating the tuple, unless we forward it in. The downside to such a change is it requires explicit specification of the __future type, rather than allowing it to use deduction. Julian has been looking at a way to at least allow the user to skip specifying the event type, but I don't think we can avoid requiring users to define the future value types. In the end, this may not be a bad thing, as it requires users of __future to be more deliberate with their types.

https://godbolt.org/z/vEWz6svMT

That's right. I've also included @reble in the discussion since he designed the original __future class. Another alternative would be to remove the tuple and specialize for our current use cases (event and/or one result container). However, this would be less generic. I would propose to close this PR and have an offline design discussion.

[SergeyKopienko]

For this to stop the copy from happening, changes are required for __future as well I believe. I think @julianmi may be working on this already, we have discussed it a little.
Here is a godbolt that shows that even with this move, it still ends up with a copy when creating the tuple, unless we forward it in. The downside to such a change is it requires explicit specification of the __future type, rather than allowing it to use deduction. Julian has been looking at a way to at least allow the user to skip specifying the event type, but I don't think we can avoid requiring users to define the future value types. In the end, this may not be a bad thing, as it requires users of __future to be more deliberate with their types.
https://godbolt.org/z/vEWz6svMT

That's right. I've also included @reble in the discussion since he designed the original __future class. Another alternative would be to remove the tuple and specialize for our current use cases (event and/or one result container). However, this would be less generic. I would propose to close this PR and have an offline design discussion.

I like this variant!
Due we pass only event id + 0/1param into the __future constructor now...

[SergeyKopienko]

@danhoeflinger, @reble I wrote new issue about our __future implementation: #1776

[SergeyKopienko]

@danhoeflinger , please take a look to this PR again.
Probably this __future implementations is ok for us?
Also I fixed issue #1776 here.

[SergeyKopienko]

We made decision together with @akukanov and @danhoeflinger to postpone this PR.
So I clear milestone state and change it's state to Draft.

[SergeyKopienko]

@reble please take a look to this draft PR and take anything if it's useful for you.