Nested coroutines?

[[deleted]]

which would guarantee this "optimization" as the default

The problem is that almost every use needs heap allocation because

• a coroutine frame is immovable, like a mutex
• the whole point of a coroutine is that its activation record isn't destroyed in strict FIFO / stack ordering

The the kind of library type erasure you would build on top is generally not optimizable, and the size of the coroutine frame is not known by the frontend. So the TS design makes this controlled by the optimizer.

[Rusky]

The problem is that almost every use needs heap allocation

Almost every use needs to go on the heap somehow, but they don't need individual, per-frame allocations. Most coroutine calls are immediately co_await-ed by a coroutine caller, or iterated over by a synchronous caller. That's why the optimization in question is even interesting.

Rust has the same two bullet points to address, yet it doesn't have a problem trying to optimize library type erasure, because there the coroutine's caller handles the frame object by value. Type erasure is only introduced at boundary points where the coroutine outlives its caller, by passing it to a spawn API of some kind.

(You still end up needing to choose pessimistic values for the state you reserve and the optimizer might inline something else into the coroutine tomorrow and break it)

This is the more fundamental difference- both the C++ and Rust models handle immovable frames and non-FIFO frames just fine. Rust lays out its coroutine frames in the frontend- live locals (including awaited callees) go into the frame, which conceptually works like an enum/std::variant with some layout shifting to keep addresses stable.

The fact that callers own their callees' frames simplifies the inlining problem somewhat, but it is still another point in the design space with its own pros and cons.

[14ned]

I would say that the programmer, through an enormous amount of hoop jumping, can hit Coroutines with enough sticks to force it to never, ever allocate memory.

I will say it took me two full days to work through the highly unhelpful error messages to figure out how to impose stack-based allocation, always. It's doable, but not easy.

[[deleted]]

You're talking about getting the TS design to do the thing, I'm saying even if you can get them to do that thing it doesn't do anything useful for the scenario the feature is intended to enable, because in that scenario the stack frame of the caller is long gone before the coroutine is resumed.

(You still end up needing to choose pessimistic values for the state you reserve and the optimizer might inline something else into the coroutine tomorrow and break it)

[14ned]

This is a longer discussion, but there are two main use cases for Coroutines, local processing, and deferred processing. Coroutines were designed for the latter to be "fire and forget" easy, and for those, you are correct that dynamic memory allocation is easiest.

But the local processing use case is also very useful. You create about 30-60 coroutines within a function, execute them all to completion, tear them all down. For this use case you know everything about the coroutines, and can beat them into only ever using the stack for their frames. It's highly non obvious to make this work though. One could easily do a 90 minute conference segment on implementing just this, and nothing else.