mostly out of ignorance on my part – just how untenable is the 'do nothing' approach to this issue? since people are already functionally able to get much (most?) of this behavior today via unstructured Tasks, does that leave performance (and maybe ergonomics/convenience/aesthetics) as the primary motivator? personally i still don't feel i have a good sense of how pressing the need is after reading the proposal. can anyone speak to that a bit more? the language will take on more complexity to support this right – how does that stack up against the status quo?
one thing i think was mentioned earlier, which i will repeat here – if cancellation 'shields' are introduced, then the semantics of all existing Task.*cancel* methods will be implicitly & subtly altered. Task.isCancelled, for example, will no longer necessarily 'do what it says on the tin', which seems rather unfortunate. additionally, i'm not sure that's the sort of thing that lends itself to being 'progressively disclosed' particularly well – how will a developer transition from thinking isCancelled means 'is cancelled' to thinking it means 'is probably cancelled, unless some other (maybe unusual?) condition is true' without a period of confusion/annoyance where their original mental model is broken? perhaps put another way – how will the documentation of Task.isCancelled et al. be changed to explain the interactions with these capabilities? as an aside: i also think such documentation changes should be bundled with shipping a feature like this.
it seems the 'Trio' python library has been a source of various inspiration for Swift's concurrency design. i've seen it mentioned a number of times now, and suggested that it contains things Swift may wish to adopt in the future (this being one of them). my naive understanding of its API is that there are cancellation 'scopes' and these scopes can be initialized with certain values that can be customized (e.g. whether or not there is a 'shield' active).
the pitch here seems pretty focused on solving this one issue, but is there a broader vision to (eventually?) support some of the other affordances which that library offers? i think timeouts have already been raised, and not too long ago there was this post from Joe regarding cancellation scopes/tokens: [Pitch] Structured Task Cancellation Tokens - #9 by Joe_Groff.
on the matter of naming... i think Freddy made a good summary case for the current choice, and i think it would be a reasonable pick. personally i think 'barrier' or something with the word 'scope' might have some potential, but it might not be that great an improvement.