Title
sender unaware coroutines should be able to co_await a task
Status
new
Section
[task.class]
Submitter
Dietmar Kühl

Created on 2025-08-31.00:00:00 last changed 2 weeks ago

Messages

Date: 2025-08-31.00:00:00

The task type doesn't have an operator co_await(). Thus, a task can't be co_awaited directly from a coroutine. Using as_awaitable on the task object also doesn't work because this function requires a reference to the promise as second argument.

task could define an operator co_await() that returns an awaitable object or directly provide an awaiter interface. There are, however, two complications:

  1. For scheduler affinity the task needs to get a scheduler from the object starting the task. While the promise can be obtained from the coroutine handle passed to await_suspend() these normally wouldn't have an associated environment supporting a get_scheduler query.
  2. The approach to reporting cancellation is to call a function unhandled_stopped() on the promise type which is generally not available. It could be argued that cancellation isn't really a problem because the it is unlikely that the environment associated with the promise supports a get_stop_token query.

It is worth noting that senders in general do not support an operator co_await(), i.e., other senders are also not awaitable directly. On the other hand, task could become the generic adapater to make senders awaitable from coroutines.

History
Date User Action Args
2025-08-31 00:00:00admincreate