> On 13 Jul 2016, at 20:04, Pierre Habouzit via swift-evolution > <swift-evolution@swift.org> wrote: > > I strongly disagree that the two forms should be named differently, it’s even > more confusing that if you use after() you get one clock and at() the other. > Also when we will add a 3rd clock to dispatch, it just stops working > completely (look at clock_gettime() that was finally added to macOS, it has 3 > interesting clocks: MONOTONIC, UPTIME, and WALLTIME that posix calls REALTIME > for some weird reason). > > the functions should exactly differ with the argument tag to show that they > basically perform the same task with a slight difference that is the clock > you’re using. It’s concise, unambiguous, and regular with the other functions > in the Dispatch module that handle time. Which in my opinion goes exactly in > the direction of SE-0118.
Methods taking DispatchTime or DispatchWallTime parameters have duplicate implementations. Shouldn't they be generic? public func wait<T: DispatchTime>(timeout: T? = nil) -> DispatchTimeoutResult As I mentioned in the review, DISPATCH_TIME_FOREVER can be represented as an Optional parameter, so `distantFuture` isn't needed. group.wait(timeout: DispatchWallTime() + .seconds(10)) group.wait() DispatchTime would be a protocol, and the existing structure would be renamed. public protocol DispatchTime: Comparable, RawRepresentable { var rawValue: dispatch_time_t { get } init(rawValue: dispatch_time_t) init() } -- Ben _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution