So, this was my primary objection during the standardization of coroutines for C++20. Red Hat's vote was consistently against adding the feature without library support, but here we are.

Lewis Baker (formerly at Facebook) has led most of the work since on defining what that library support might look like. The library where he has done most of his exploration on the matter is -

I spoke a bit this morning with one of the C++ committee members most directly involved in where this is going standardization-wise and the takeaway about the current expectations is -

C++23 is likely to get at least some minimal library support in the form of -

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2502r1.pdf

Which defines a generator<T> that models std::ranges::input_range.

But, for anything that involves a library for scheduling asynchronous execution of coroutines (e.g. tasks<T>'s) on different execution contexts (threads) that is likely not going to happen until C++26.

I wish I had a better story to tell.

Tom.

On Tue, Apr 19, 2022 at 4:32 AM Florian Weimer <fweimer@redhat.com> wrote:

* Stefan Hajnoczi:

> On Tue, Mar 01, 2022 at 12:54:49PM +0100, Florian Weimer wrote:
>> > I took a quick look at C++20 coroutines since they are available in
>> > compilers but the primitives look hard to use even from C++, let alone
>> > from C.
>>
>> Could you go into details what makes them hard to use? Is it because
>> coroutines are infectious across the call stack?
>
> Here is the simplest tutorial on C++20 coroutines I found:
> https://itnext.io/c-20-coroutines-complete-guide-7c3fc08db89d
>
> The amount of boilerplate for trivial coroutine functions is ridiculous.

Would an execution agent library reduce that usage overhead?

Cc:ing Thomas, who might know the answer.

Thanks,
Florian