> On 13 Jul 2016, at 20:04, Pierre Habouzit via swift-evolution
> <[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
