TS generators can only access the promise indirectly through co_yield. Macro based coroutines can access the promise area directly, and can use it to pass information in to coroutines as well as get information out. For example a coroutine that begins on one thread could be resumed on another thread; passing a pointer to thread specific information in the promise structure could be faster and more disciplined than using a thread_local variable for the same purpose.
One possible implementation would be to have a keyword co_promise that returns a pointer to the promise, analogous to the "this" pointer for accessing member variables.
Another useful way to pass information into the coroutine would be to allow the promise to set the type signature of the resume function. For example if we wanted to send the current thread data to a coroutine resume in a register we could have
struct promise_type
{
using resume_type = void(*)(void*, some_thread_specific_data);
...
If you think any of these proposals have any chance of moving forward I would be willing to take a crack at them in Clang. I think the new coroutines are best thing to happen to C++ since lambdas, but I really want them to be better in every way than the macro-style coroutines people use today.
TS generators can only access the promise indirectly through co_yield. Macro based coroutines can access the promise area directly, and can use it to pass information in to coroutines as well as get information out. For example a coroutine that begins on one thread could be resumed on another thread; passing a pointer to thread specific information in the promise structure could be faster and more disciplined than using a thread_local variable for the same purpose.
One possible implementation would be to have a keyword co_promise that returns a pointer to the promise, analogous to the "this" pointer for accessing member variables.
Another useful way to pass information into the coroutine would be to allow the promise to set the type signature of the resume function. For example if we wanted to send the current thread data to a coroutine resume in a register we could have struct promise_type { using resume_type = void(*)(void*, some_thread_specific_data); ... If you think any of these proposals have any chance of moving forward I would be willing to take a crack at them in Clang. I think the new coroutines are best thing to happen to C++ since lambdas, but I really want them to be better in every way than the macro-style coroutines people use today.