# \[Returned for revision\] SE-0526: withDeadline **URL:** \ **Category:** Announcements\ **Created:** [June 14, 2026, 8:32pm UTC](https://forums.swift.org/t/returned-for-revision-se-0526-withdeadline/87379 "2026-06-14T20:32:09Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Jumhyn](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jumhyn/32/3891_2.png) [@Jumhyn](https://forums.swift.org/u/Jumhyn)\ **Post date:** [June 14, 2026, 8:32pm UTC](https://forums.swift.org/t/returned-for-revision-se-0526-withdeadline/87379/1 "2026-06-14T20:32:09Z")
Hello, Swift community! The [second review](https://forums.swift.org/t/second-review-se-0526-withdeadline/86791) of [SE-0526: withDeadline](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0526-deadline.md) ran from May 18th though May 31st, 2026. The Language Steering Group has decided to **return this proposal for further revision** on the following points: - While the Language Steering Group recognizes the inherent tension between allowing deadlines for arbitrary clocks and also allowing inspection of the deadline environment for executing code, we do not think it is suitable to entirely remove the ability to observe the deadline environment from the API surface. At the same time, we do not consider the prior `currentDeadline` shape to be suitable—it is a fundamental constraint that there is not any necessary relationship or conversion between deadline instants from different clocks, and so any solution here must grapple with the fact that there cannot be a singular notion of "_the_ current deadline". - The Language Steering Group is broadly satisfied with the updated API shape that eschews the wrapping `DeadlineError` in favor of the `CancellationError.Reason` enum. However, we are not completely satisfied with the `Reason` API as proposed. - We do not think it makes sense at this point to include the `custom(String)` reason. The authors have already indicated this should be removed, but mentioning it here for completeness. - The `taskCancelled` reason seems poorly named—_all_ `CancellationError`s arise from a task being cancelled, so this name seems insufficiently descriptive compared to the `deadlineExceeded` counterpart. We would like to see a bit more consideration given to this 'default' case. The Language Steering Group was sensitive to points raised about the current behavior when passing `nil` values for the `tolerance` parameter on `Task.sleep`, which `withDeadline` would inherit. However, the Group does not believe that this proposal is the appropriate vehicle to which to attach updated behavior. The Group encourages discussion on this point to continue in a separate thread to determine what the appropriate behavior for default-tolerance _should be_ as well as whether it would require an evolution proposal at all (as opposed to being treated as an implementation detail bug fix). Once the authors have addressed the above points of feedback we will bring the proposal back for another round of review. Thank you to everyone who participated in this review! Freddy Kellison-Linn Review Manager ---
**Author:** ![Jon\_Shier](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jon_shier/32/921_2.png) [@Jon\_Shier](https://forums.swift.org/u/Jon_Shier)\ **Post date:** [June 14, 2026, 10:59pm UTC](https://forums.swift.org/t/returned-for-revision-se-0526-withdeadline/87379/2 "2026-06-14T22:59:31Z")
> [@Jumhyn](#): > > - The `taskCancelled` reason seems poorly named—_all_ `CancellationError`s arise from a task being cancelled, so this name seems insufficiently descriptive compared to the `deadlineExceeded` counterpart. We would like to see a bit more consideration given to this 'default' case. Unfortunately I'm not sure there's much we can do here, as there is no useful information available to make the naming more clear, such as whether cancellation was due to manually calling `cancel` or automatic. Perhaps something like `runtime` or `structured`? Defined something like "cancellation caused by manual action or automatic propagation through structured concurrency". But really, this default because can, itself, be caused by the failure of a deadline, so at some point they're really the same thing. ---
**Author:** ![pyrtsa](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/pyrtsa/32/740_2.png) [@pyrtsa](https://forums.swift.org/u/pyrtsa)\ **Post date:** [June 15, 2026, 7:09am UTC](https://forums.swift.org/t/returned-for-revision-se-0526-withdeadline/87379/3 "2026-06-15T07:09:00Z")
> [@Jumhyn](#): > > - The `taskCancelled` reason seems poorly named I think it would be sensible to just say that there's no particular reason in this case, so `reason` should be `nil` (and thus have an optional type).