Rainer Deyke wrote:
This isn't about Capy vs TooManyCooks. This is Capy vs an entire world of C++ coroutine code that can interact with each other more or less seamlessly.
That's very far from the truth today, and it's probably never going to be true unless something like Capy is adopted as standard. Everyone that tries to write a coroutine library starts out with this interoperability goal in mind, and then gradually arrives at the conclusion that it's unattainable, and Capy followed the same path. The problem is that there needs to be a standard way to propagate important state to the foreign coroutine, so that the foreign coroutine can at least propagate that same state back to you if it co_awaits one of yours. That state in Capy consists of the executor, the stop token, and the allocator. And while you can argue that the allocator is optional (but it isn't in practice), the other two most certainly are not. If every co_await can switch your coroutine to some arbitrary executor, the model becomes wildly impractical and everyone using coroutines in practice eventually arrives at the conclusion that coroutines need to be resumed on the executor they started on (apart from obvious explicit constructs that switch, e.g. `co_await resume_on( ex );`.)