Missing std::experimental::async

[viboes]

As async returns a std::future and we are adding a std::experimental::future it seems to me that we need to add an async function in std::experimental that returns a std::experimental::future.

Maybe it is worth changing the semantics of async and return a future that doesn't block on destruction.

[arturl]

This is a good point but then we would also need to add TS-compatible promise and package_task right?

How about we introduce conversion methods between std::future and std::experimental::future?

We should look at how other TSs solve this.

[jwakely]

They don't solve it, but they should do - conversions would be useful

[villevoutilainen]

I would expect it to be somewhat controversial to change the semantics of async.

[hkaiser]

I would expect it to be somewhat controversial to change the semantics of async.

I wouldn't say this changes semantics of std::async. This would introduce a new facility with a different name which exposes semantics different from std::async.

[villevoutilainen]

I was specifically responding to the bit "Maybe it is worth changing the semantics of async and return a future that doesn't block on destruction. " And putting it into a different namespace than std::async doesn't quite qualify as "a new facility with a different name" to me.

[viboes]

@arturl Yes, we need to duplicate any class/function that make use of std::future/shared_future on its interface.
Conversions will be really useful, but they can be provided only intrusively, that is, you need the std sources in order to implement the conversion to/from experimental, which forbids the implementation of a TS by a third party. So these conversions should be optional.

[viboes]

@villevoutilainen We need to add async (or something like that) on the experimental namespace, this is a fact, otherwise the users of std::experimental:: will have less functionality that the std:: ones.
We can preserve the std::async semantics or not, as this is a TS or we could also use a different name, if maintaining it would be too controversial.
This is independent however of whether we want to introduce a breaking change for C++17 or not, as a TS must be adapted before going to the standard.
The advantage I see adding a function that returns a not blocking future is that this allows to experiment before taking a decision for C++17.
I wonder if a good compromise isn't to add both to std::experimental.

[viboes]

When I said both I was referring to a blocking and a non blocking version. The blocking version should return a different blocking_future type. In this way all the experimental::future instances will be not block.

[K-ballo]

I don't think an std::experimental::async should introduce different semantics. As far as I know, all these suggestions were proposed and rejected. If that's the case, we should stick with std::async semantics (or propose something new?).

[arturl]

@K-ballo: I agree, we're not attempting to fix std::async (executors is the real solution), only to introduce a version that returns std::experimental::future.

@ALL: Can someone write up a proposed change for N4123 with the text for the new std::experimental primitives and send me a pull request? I still need to process a bunch of other issues that Vicente sent me, and the deadline is approaching.

[viboes]

@K-ballo IIRC the proposals that were rejected were for C++14 not for a TS.

@arturl I will try to send you something this weekend. We need to add promise, packaged_task and async. There will be still an issue: promise and packaged_task are already on experimental namespace from the Fundamental TS :(