[Returned for revision] SE-0526: withDeadline

Evolution Announcements
1

Hello, Swift community!

The second review of SE-0526: withDeadline 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 CancellationErrors 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

4 Likes
2

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.

3

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).

7 Likes