Thank you so much everyone for your feedback on our proposal. We are grateful that you are all taking time to share your experiences and humbled that so many of you believe this is a great addition to the Swift language.
Based on the feedback here and elsewhere, we've updated the proposal to remove the explicit cancel
call. There are two main reasons:
- Reducing the requirements of implementing
AsyncIteratorProtocol
makes it simpler to use and easier to understand. The rules about whencancel
would be called, while straightforward, would nevertheless be one additional thing for Swift developers to learn. - The structured concurrency proposal already includes a definition of cancellation that works well for
AsyncSequence
. We should consider the overall behavior of cancellation for asynchronous code as one concept.
We also took the opportunity to fix a few small naming issues in the proposal.
An additional thought, not included in the 'alternatives considered' because it is more speculative: the existence of Task.checkCancellation
should also provide those that need async
cleanup on cancellation or completion a path to do so (in async next
). Those implementations that do not need async
cleanup can still do so in next()
or in deinit
.