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

[Karl]

> On 13 Jul 2016, at 21:04, Pierre Habouzit <phabouzit at apple.com> wrote:
> 
>> On Jul 13, 2016, at 11:42 AM, Karl via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>> On 13 Jul 2016, at 19:59, Daniel A. Steffen <das at apple.com <mailto:das at apple.com>> wrote:
>>> 
>>> I’m confused, that is what we have in the current version (the argument label is part of the overall method name): asyncAfter(deadline:) vs asyncAfter(wallDeadline:), which is consistent with all the other labels of deadline arguments in the API (this isn’t the only method dealing with time)
>>> 
>> 
>> I think this argument labels are superfluous and actually make the meaning less coherent. “after(when:…)” is not grammatically fluent, which the Swift API guidelines encourage, and which the standard library has made big steps towards recently (see especially https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md <https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md>). By dropping the labels and renaming the function base-names, we make them more “swifty”, more concise, clear and readable, and can improve safety by making sure people know which clock they’re using and what semantic meaning that has. 
> 
> after(when:) is the current state of the overlay but we told you we’re proposing something new, so your argument is not in complete good faith here is it? ;)

Yeah, I know - you’re proposing to rename it, I’m proposing that it should have a different type (which would be enabled by a different renaming to the one you’re proposing). So I think it’s a fair debate. I gave my opinion on “deadline" - the time you specify isn’t actually a deadline, is it? It isn’t the latest possible the time the block is allowed to execute; it’s the earliest possible time.

Maybe there is a language gap in there, maybe people use “deadline” more loosely to mean a general point in time in California, but the dictionary agrees that deadline means "the latest time or date by which something should be completed”, which is not what I think you mean (maybe I’m wrong, but that’s my understanding of what you’ve been saying so far).

> 
>>> we did discuss naming these asyncAt() instead of asyncAfter(), which would make it more clear that they take a deadline, but the name felt uncomfortably close to async(), and may also lead to the mistaken impression that the execution with occur exactly _at_ the deadline (as opposed to just the async() to a queue that may be full of other items already and take a while to drain, or be suspended and never execute at all)
>>> 
>> 
>> I’m not sure it’s really necessary to include the word “async” in there — it’s pretty clear from the fact that they take a time that they’re not going to block.
>> 
>> The problem with “deadline” is that it’s just not a deadline. It’s an aspirational fire time, and Dispatch should execute the block as soon as possible after that time. I can’t really think of a concise word for it, but “deadline” does not express what you’re talking about. Deadline implies that the block can execute any time _before_ the specified time.
>> 
>> So that’s where I get “at” from; if your app is asleep, it isn’t possible to execute exactly at the specified time for reasons outside of your control. If it executes as soon as possible after waking, I would still consider it to be firing “at” the correct time (in a loose sort of way). If we were talking about the dispatch queue as a person, and I asked him/her to do something at a particular time, but they were delayed due to circumstances outside of anybody's control (like a natural disaster or a traffic accident), I’d still consider that they did it “at” the correct time, again in a loose sense - to the best that they can control it, in other words.
> 
> 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.
> 

Didn’t we agree earlier that the clock type is not a minor distinction? And that there are rather large differences about when the block might fire depending on which clock you use. This was Anthony Chievetta (maybe I misunderstood him, too):

> I disagree strenuously: it’s a super important distinction that is frequently the cause of subtle but bad bugs!
> 
> Lets start with the fact that you (presumably not the novice user you describe below) actually got the difference between the two clocks wrong.  Here’s the current behavior (on Darwin, not sure what Linux currently implements):
> 
>   - DispatchTime is a clock that only advances forward and tracks the amount of time the computer is awake.
> 
>   - DispatchWillTime is a clock that tracks as a UTC clock would, generally moving ahead during sleep, but is *not* monotonic.  It can move forward, backward, upside down, whatever it wants.  And frequently it will.
> 
> And this stuff is hard: if you are writing a tea timer app and you pick either of these, you have a bug.  DispatchTime, the bug is that if the user locks their device and it falls asleep the alarm won’t fire upon wake.  DispatchWallTime, if the device realizes its clock is ahead or behind the “real” time the elapsed duration won’t be what you expect.  (Should we have a third that works for the tea timer? Absolutely…)



If there is some new clock introduced later, with different scheduling guarantees, it can get its own unique name to reflect what it does, right?


>>>>> 
> 
> 
> This was an example was to give you a sense of why what you’re asking feels wrong to us. But if you want a better one: dispatch_after() is completely suitable to have a notification in app when a given wall time passes if you’re in the app. It avoids the overhead and headaches of complex notification mechanisms, which are sometimes not even desired (if you’re not in the app, having the system wake up for that timer is a power issue). There are several apps doing that.
> 
> We hence don’t think that what you’re asking for is serving developers.
> 
> also note that the C API works that way for a long time:
> 
> dispatch_after(dispatch_time(DISPATCH_TIME_NOW, …), …)
> dispatch_after(dispatch_walltime(DISPATCH_TIME_NOW, …), …)
> 
> to me it’s visually similar to:
> 
> q.asyncAfter(deadline: .now() + …) …
> q.asyncAfter(wallDeadline: .now() + …) …
> 
> And while making things more swifty (and DispatchWorkItem shows that we’re dedicated to that when there’s a benefit), making it too dissimilar to the C interface for no good reason is something to IMO consider when picking names here.

The C API was also horrible in that regard. I bet there’s not a handful of people on this mailing list who could tell you exactly how to invoke dispatch_after. Everybody just uses the Xcode macro because it’s a mountain of jargon that almost nobody needs to care about.

That’s the whole point of all of this - I’m not proposing removing functionality, just making it more obvious and intuitive. If these clocks have such enormous differences, they should have unique names to reflect that — and since we now know the clock, we can supply defaults and take intervals rather than absolute times, making the names fluent and clear.

That’s why I think my proposed change is so much for the better - it leads to massive simplifications all-around, and things will just make so much more sense afterwards, without reducing functionality. Nuances that were hidden will be exposed, and you won’t need to dig through interfaces looking for operator overloads any more - autocomplete will be able to tell you exactly what to enter.

That’s why I’m not disparaged by how many of you Apple guys disagree - after all, you guys designed the original C API that this very-closely follows (which is a great API, don’t get me wrong, but this function hasn’t adapted to Swift yet IMO). It could be clearer and more approachable for end-users.


Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160713/1e4ca73a/attachment.html>