[cpp-threads] Asynchronous Function Proposal

[Herb Sutter]

> > I don't understand that last part. Of course there's a single
> > call site; you always start a function (and now async task)
> > in one place. But of course there can be multiple consumers of
> > the result of the computation; you often use the result (and now
> > future<result>) in multiple places.
> 
> To use the result in multiple places in sequential code, you must
> store the function result in a variable and then copy it around.  The
> situation is no different with a single-invocation async_future::get.

No, I'm sorry but that's unreasonable to assume/require/enforce. This fails to distinguish between spawning (or sending a message to) other code that needs to receive the result immediately vs. that needs to use the result eventually. Sometimes the former is fine, but often it's not when you don't want to be forced to collapse concurrency.

In async code, the corresponding sentence is usually found by doing s/result/async result/, in this case:

  To use the aync result in multiple places, you must store
  the async result in an async variable and then copy it around.

i.e., as a shared_future. There's no problem with doing this if you use packaged_task/unique_future directly, which is what async() is supposed to wrap/hide.

You do not want to force people to lose concurrency. Forcing that is a non-starter. The proposal needs to be changed to return unique_future anyway for several reasons, but this is one of them.

I haven't read the revision yet, but the first serious problem is that it didn't switch to unique_future.

Herb