My kneejerk reaction was "That sounds bad! Every suspend point would become an invisible interruption point — you couldn't hold a resource across a suspend point without careful planning!"

That's indeed the goal you might have. Now, of course, holding a resource across suspension points is completely acceptable, as long as you're following RAII principles (so your 2nd example of using a raw memory allocation is unsafe by modern C++ standards). The reason I think having a more automatic form of cancellation is a good thing is because it's useful to have built-in ways to cancel a long-running operation, such as a file download/upload, a long asynchronous wait, ...

Right now, if we would want to cancel (for any reason) we're forced to use the very verbose std::stop_source and std::stop_token.

What I'd like is to have a standardised promise type for coroutines which could support cancellation. I don't see a reason forcing every user to create their own promise type or rely on libraries for promise types. If the standard is providing a runtime, then we should provide a promise as well, and in my opinion, that promise should be able to be cancelled.

Mind you, I don't think this promise should cancel itself by default (although there's also some benefits to that), but as a first implementation, this standard provided promise could provide a cancel() function, which will cancel the coroutine at the earliest opportunity.

Op do 9 apr 2026 om 15:42 schreef Arthur O'Dwyer <arthur.j.odwyer@gmail.com>:

On Sat, Apr 4, 2026 at 5:04 AM Rhidian De Wit via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

I've been reading up a bit on C++26 std::execution and I noticed that for cancellation we still use the `std::stop_token` approach to be able to "cancel" a coroutine by forcing the user to always call `stop_requested()` before continuing the coroutine, in addition to needing to pass a `std::stop_source` or `std::stop_token` around, making it pretty inconvenient to use.

Now, there are ways to make this more automatic, for example, by embedding the `std::stop_source` in the coroutine's promise type and checking at every suspension / resumption point (`await_suspend()` and `await_resume()` respectfully) whether or not the coroutine has been cancelled. If so, you can throw an exception and let the coroutine unwind itself.

I was wondering if there is a proposal for such an automatic cancellation feature in the works or already present?

I am relatively uneducated in this area; but no, I'm not aware of any plan or proposal to embed a stop_token into every coroutine.

My kneejerk reaction was "That sounds bad! Every suspend point would become an invisible interruption point — you couldn't hold a resource across a suspend point without careful planning!"

But then I thought again, and realized that we already have that. The caller is the one who decides whether to resume a coroutine_handle<>; if the caller decides to destroy() it instead, well, that suspend point just turned into an invisible abort anyway, from the coroutine's point of view.

Example of safely holding a resource across a suspend: https://godbolt.org/z/azTW57qf8

Example of unsafely (leakily) holding the same: https://godbolt.org/z/f4rTG7Kh3

But then I'm afraid I don't understand what feature you're asking for. You can already "tell a coroutine to unwind itself" by just destroying the handle you were using to talk to it. Why would you also need a stop_token/stop_source to be involved? Are you trying to stop someone else's coroutine, like from another thread, without the participation of its owner? But then what do you expect the coroutine to do — report .done() despite not having reached the co_return statement, I guess? Which means what — call .final_suspend() on the promise without having first called either `.return_value()` or `.return_void()`? Is that something that's possible to do today (except manually)? Why would I want that?

In particular, adding the ability for the compiler to generate a new and unusual sequence of calls to my promise type means suddenly there's a lot more surface area I'd need to cover in my promise types' unit tests to make sure they're not buggy/leaky even in this new special case.

HTH,

Arthur

--

Rhidian De Wit

Software Engineer - Barco