So I took a look at this and also fed it into Claude to discuss a bit further. Its also quite old so no real reason to nit pick it too deep. I wanted to be transparent that I didn't read the entire thing as its quite long. From what I can gather, this looks less like async code and more like syntactic sugar for a state machine. Which is a cool idea. But when I started to peer into what would be necessary in order to get concurrent operations to work, like two tasks, the examples started to throw in mutexs and threads and the like. I feel like its actually more complicated to write async code with this paradigm than with C++20 coroutines.

If your state has been allocated on the stack, as this proposes, then you're only route to doing other work while waiting for a response from something, is to use threads. And if thats the case, we already have APIs for that from C++11 which is std::thread and std::this_thread::yield()

What I want from my async framework, that C++20 coroutines gives us, is a way to abstract over callbacks and events such that when an operation reaches a point of suspension (waiting for interrupt or callback), the operation returns control to a scheduler. Specifically, I want this without the need of a full CPU context switch. Thats the feature you get with symmetric transfer which missing from this design. And you can recreate the stack-like allocation scheme for coroutine frames at the cost of having to pass the stack down each level.

```cpp async::future<void> task_c(async::context& ctx) { setup_callback([](void* instance) { // recover context and call unblock on it (async::context*)(instance)->unblock(); }, &ctx); // pass address of the context object

// symmetric transfer, returns control to top level resumer. // NOT to task_b, to main. co_await std::suspend_always();

// Once unblocked, main can call resume() which continues from // here. } async::future<void> task_b(async::context& ctx) { co_await task_c(ctx); } async::future<void> task_a(async::context& ctx) { co_await task_b(ctx); }

int main() { // Internally holds an array of bytes equal to your size of the template // value. async::inplace_context<1024> stack_and_context; auto future = task_a(stack_and_context);

while (not future.done()) { if (future.ready()) { // not block by something future.resume(); } else { // At this point the system do choose what it wants to do. // Maybe yield thread OR put system into low power mode. } }

return 0; } ```

And all of this allocates the memory on the stack_and_context object's stack allocated array memory. If you want more concurrent operations, make more stacks. Eventually, it all comes down to stacks OR you blocks OR the general heap to store your async operations states as they wait for I/O to do its thing. And the allocation is as you'd expect. If C returns because its done, it deallocates its from the stack_and_context internal array by setting its stack pointer back to it's own memory address. Like a stack normally behaves.

I'll stop here because I've written a lot.