[swift-evolution] [Idea][Swift 3] Change 'DispatchQueue.after' to take a relative time + clock (with default). Maybe replace clocks with an enum?

[Ben Rimmington]

> On 13 Jul 2016, at 20:04, Pierre Habouzit via swift-evolution <swift-evolution at 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