This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

4338. sender unaware coroutines should be able to co_await a task

Section: 33.13.6.2 [task.class] Status: New Submitter: Dietmar Kühl Opened: 2025-08-31 Last modified: 2025-09-01

Priority: Not Prioritized

View other active issues in [task.class].

View all other issues in [task.class].

View all issues with New status.

Discussion:

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.

Proposed resolution: