[cpp-threads] Asynchronous Function Proposal

[Herb Sutter]

Peter wrote:
> I do not agree with your choice of (only) providing a policy that executes
> on get(), neither do I agree with the choice to remove wait, has_value and
> has_exception because of it. Furthermore, the name "must_be_called" does not
> make sense for this policy, because it in fact never calls the function
> unless there is a get() call.
> 
> The sensible policies are (in my opinion):
> 
> - at implementation's discretion (default)

Yes, meaning "might execute synchronously on this thread."

> - launch in a thread pool
> - launch in a separate thread

I don't see the need to distinguish these. The only thing the user cares about is "guaranteed not to execute synchronously on this thread."

I was about to say I'm not opposed to distinguished these, but then I remembered we don't have thread pools so now I am opposed because allowing that one will stir controversy. ;-)

> - execute immediately (for generic contexts)

Yes, but that is needed (only?) for testing and would be routinely provided as a QoI extension. No harm in providing it though.

> - defer until wait() is called (not get)

I'm not opposed to including something like this, but I have seen no experience with it or need for something finer-grained than "execute immediately." Is there?

> I think that an enum parameter may be better as a policy because it would
> allow the choice to be made at runtime.

Yes, and it's simpler.

So I would (strongly) suggest having only:

  enum AsyncPolicy {
    /* default, might run synchronously or asynchronously */ ,
    /* guaranteed to run asynchronously on another thread */ ,
    /* guaranteed to run synchronously on this thread */
  };

That boils it down to the two important and mutually exclusive cases the user cares about and an "implementation-defined" default, which is complete and readily explainable. Is there a need for something more?

Herb