Swift Concurrency’s core design strongly signals an intent to support tasks actors and executors with custom clocks. Introducing an API that only works if the task only ever executes on actors that use ContinuousClock seems like a significant retreat from that design goal.
Since this API is implemented atop cancellation, which any task is free to ignore and/or suppress from propagating to its child tasks, I believe it is reasonable to allow this API to fail in certain scenarios for the sake of extending compatibility to other Clock types.
The specific changes I would recommend for this proposal are:
Rename the method to withAutomaticCancellation()
This makes it more obvious that the Task may successfully complete even if it observes deadline expiry.
Make the function generic over a Clock instance
Compelling reasons for this have already been given by people who are actively using custom Clocks in testing.
Return the canceled Task
I am unconvinced that withAutomaticCancellation() must always await the original Task before returning. The cases where it’s needed for program correctness are cases where the user must already avoid wrapping their work in Task.detached { }.
I believe withAutomaticCancellation() should return immediately after canceling the task if the deadline expires. The return value will contain the wrapped Task, so that the user can choose to await its value if necessary for program correctness. But in cases where the work can continue executing in a detached state, the application can simply ignore the Task and avoid the penalty of synchronizing on it.