The third review of SE-0526: withDeadline concluded on July 12th, 2026. The Language Steering Group has decided to accept this proposal with the modification that the CancellationError.Reason.userRequested case be renamed to unspecified as raised during review.
The reception of the third revision of this proposal was largely positive aside from some questions and suggestions about API naming.
The LSG would also like to state its position on a question that came up during implementation of this proposal: it is acceptable, as an optimization, for the withDeadline implementation to avoid creating a formally separate task for executing the body so long as all language behavior remains as-ifbody were executing in a separate task (with respect to cancellation behavior, etc.). This should not matter for most purposes, since available APIs will definitionally not be able to observe the difference. But it may be the case that, e.g., the debugger reports body as executing with the same task ID as the caller of withDeadline.
Thank you to everyone who participated in the review for helping to make Swift a better language!
Will this be included in Swift 6.5? There's no mention of this feature in Swift (next) yet.
The implementation includes @available(StdlibDeploymentTarget 6.5, *), but it needs to be clarified whether this reflects the accepted internal decision.
For whatever reason, Apple has largely stopped updating the Swift CHANGELOG or Xcode release notes with Swift features. Closest we have right now is John's recent list, which indicates withDeadline will be part of 6.5.
I believe the implementation is still technically in progress, and we can’t commit to anything being in a particular release until it’s actually happened. But yes, it’s expected in 6.5.
I believe the implementation is still technically in progress, and we can’t commit to anything being in a particular release until it’s actually happened. But yes, it’s expected in 6.5.
It's fully implemented, pending one internal optimization but it doesn't surface in any observable way so this is already landed and I'd expect it to ship in the upcoming version, with or without the additional optimization (which would depend on new executor pitches).
I have one more question. The current implementation relies heavily on compiler's internal mechanics and new concurrency infrastructure. Because of this it isn't feasible to simply extract the solution into a backport overlay for older OS versions (as e.g. Disconnected or MutableRef).
To help understand the evolution of this feature, could you share how closely the final implementation aligns semantically with @FranzBusch original proposal? Additionally, were there any subtle edge cases, concurrency pitfalls or non-obvious behaviors that the final version addressed and refine along the way?
Or perhaps there is an implementation that uses the Swift 6.4 concurrency public API, which generally works correctly and can be used until the final version is released in the next Swift release.
Semantically, the implementation is matching what I originally proposed with regard to the cancellation semantics. However, the implementation in 6.5 differs in how it handles nested deadlines of the same clock since that required Concurrency runtime internal support which is not easily replicable with the 6.4 public APIs.
The best implementation to back port is probably just using a task group with two child tasks that are raced against each other.