Should Clock.sleep(for:) be added?

[mbrandonw]

The Clock proposal calls out 3 ways of sleeping, 2 on Task and 1 on Clock:

Task.sleep(until:)  // Instant-based
Task.sleep(for:)    // Duration-based
clock.sleep(until:) // Instant-based

However, there is no corresponding duration-based sleep for clocks:

clock.sleep(for:) // ❌ Duration-based

This means in order to perform duration-based sleeping, which is usually more ergonomic, you have to resort to the longer Task.sleep method:

try await Task.sleep(for: .seconds(1), clock: myClock)

// vs

try await myClock.sleep(for: .seconds(1))

Should this 4th variation of sleep be added to the standard library to be consistent?

[ktoso]

It was in the accepted proposal, so I believe thats an omission -- right @phausler ?

[ktoso]

Specifically the proposal listed:

extension Task {
  @available(*, deprecated, renamed: "Task.sleep(for:)")
  public static func sleep(_ duration: UInt64) async
  
  @available(*, deprecated, renamed: "Task.sleep(for:)")
  public static func sleep(nanoseconds duration: UInt64) async throws
  
  public static func sleep(for: Duration) async throws
  
  public static func sleep<C: Clock>(until deadline: C.Instant, tolerance: C.Instant.Duration? = nil, clock: C) async throws
}

https://github.com/apple/swift-evolution/blob/main/proposals/0329-clock-instant-duration.md

[phausler]

Correct, it was some of the very last iterations; the deprecations are obviously the next step but we can do those later to avoid churn.

[mbrandonw]

Unless I'm missing something in the proposal, it does not seem that clock.sleep(for:) was ever proposed. There's clock.sleep(until:), and Task has both variations: Task.sleep(for:) and Task.sleep(until:).

Was it an oversight to not include clock.sleep(for:)? Does it require evolution approval to be added?

[mbrandonw]

Any update on this? Can this be added before Swift 5.7 is finalized?

[mbrandonw]

Just wanted to mention some concrete problems that arise from not having these functions.

Since all APIs dealing with clocks and sleeping use instants, and not durations, it is not possible to use the APIs with a Clock existential:

let clock: any Clock<Duration> = ContinuousClock()
try await clock.sleep(until: clock.now.advanced(by: .seconds(1)), tolerance: nil) // 🛑

This is because the Instant associated type gets erased but then the .sleep(until:) API forces us to construct instants.

If we had the sleep(for:) API we could make this work:

extension Clock {
  func sleep(for duration: Self.Duration) async throws {
    try await self.sleep(until: self.now.advanced(by: duration), tolerance: nil)
  }
}

let clock: any Clock<Duration> = ContinuousClock()
try await clock.sleep(for: .seconds(1)) // ✅

So, not having Clock.sleep(for:) and Task.sleep(for:clock:) makes it impossible to erase the type of a clock, which makes testing code that involves clocks very difficult.

Is there anything I can do to help move this forward? I can easily create a PR to add these functions to the standard library if it doesn't require evolution.

[mbrandonw]

And one more thing to note. We definitely need the Clock.sleep(for:) method. The Task.sleep(for:clock:) static method alone is not sufficient due to a limitation of Swift 5.7 existentials which prevents you from opening the existential if a value of the associated type is used as an argument:

let clock: any Clock<Duration> = ContinuousClock()
try await Task.sleep(for: .seconds(1), clock: clock) // 🛑

[phausler]

Adding that function (to clock) would be an evolution type change.

[mbrandonw]

Ok, posted a pitch: https://forums.swift.org/t/pitch-clock-sleep-for/60376

[benrimmington]

The new and updated APIs from SE-0374 aren't available in Xcode 14.3 beta 2 (14E5207e).

I tried using an Xcode playground for iOS; and an iOS project with a 16.4 minimum deployment.

(Other APIs introduced in Swift 5.8 are available.)

[benrimmington]

swiftlang/swift-evolution@419d000

-* Status: **Implemented (Swift 5.8)**
+* Status: **Implemented (Swift 5.9)**

[ktoso]

Yeah seems this'll come in 5.9, I think we can close this issue