On Thu, Apr 9, 2026 at 4:23 PM Lénárd Szolnoki via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> > 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.
>
> For precedence, python's asyncio has the exception model for cancellation
> (an exception of
> type asyncio.CancelledError from a suspension point when a task is
> cancelled).
>
> One thing it allows is to have asynchronous teardown logic, like
> gracefully terminating
> network sessions, deregistering from mDNS (zeroconf), etc... .
>
> In comparison simply "dropping" the coroutine (destroying the handle)
> forces the teardown
> to be either synchronous, or schedule teardown tasks elsewhere, but it's
> unclear to me
> where tasks scheduled from the destruction of coroutines can be cleanly
> joined. From what
> I heard Rust (or tokio?) has this cancellation model, but I can't comment
> on that.
>
> I know very little about std::execution to comment on that. My gut feeling
> is that
> exceptions are too heavy for C++ for a general cancellation solution (but
> I agree that it
> is ergonomic, I use it with ASIO), the stop_token is probably sufficiently
> light, but
> verbose to use, and just dropping coroutines is missing out on async
> teardown.
>

Thinking of asynchronous cancellation - specifically a socket connection
that runs TLS 1.3, as I know that in depth - there are two different bits
of "cancelling". The first is when the connection should be actively torn
down because of a TLS failure. The second is when the other side of the
connection is no longer around - ie, their client went away, stopped
responding quickly enough, or somebody disconnected our side of the
connection. In the former case, we want to have an active cancellation that
indicates "please tear down this connection and indicate TLS failure". In
the second case, we just want to clean up resources, because there's no
remote side to send the disconnection to. For context, the goal of those
errors is for the other side to know what to do with session resumption
tickets that it had received earlier.

I don't see a problem with using a stop token. The behavior is meaningfully
different for tearing down and doing the active cancellation, so somebody
somewhere is going to have to have the code to do that.

Regards,
Peter