Let's say I write a generator coroutine that gives the letters of the alphabet up until z, and then co_return's.

So let's say we invoke the routine and get a generator object from it:

        auto gen = GetAlphabet();

Next let's say that we invoke the generator 5 times giving us a,b,c,d,e. But then, before the coroutine has co_return'ed, we destroy the generator object. I haven't been able to find out from websearching what's supposed to happen if you prematurely destroy the generator object. Is it undefined behaviour?

Anyway I propose that we can mark a coroutine with [[co_clean]], and that it will have the following effect:
If you prematurely destroy the generator object, it will behave as though you invoked the generator again but immediately encountered a 'co_return', thus all the appropriate destructors will be called for local objects inside the coroutine.

This feature would be really useful for me in a networking program I'm currently writing. I have a thread that has a loop iterating through 6 generator objects calling them all in sequence. But when the thread's stop_token is triggered, it would be convenient to just return from the thread without having to gracefully end the coroutines.

As far as I'm aware, and I'm open to correction here, at the time of writing, with C++23, to get this kind of behaviour, you need to follow every co_yield with a co_return, something like:

    for ( char c = 'a'; c <= 'z'; ++c )
    {
        co_yield c;
        if ( global_boolean_to_stop ) co_return;
    }

And so then in the thread that invokes the coroutines, when the stop_token is triggered, you need to set 'global_boolean_to_stop' and invoke the generator one more time. It would be easier instead just to mark it [[co_clean]].

But of course this new feature proposal of mine won't be viable if the desired behaviour is already what happens when you prematurely destroy a generator.