<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Jul 13, 2016, at 11:42 AM, Karl via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: SFMono-Light; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On 13 Jul 2016, at 19:59, Daniel A. Steffen <<a href="mailto:das@apple.com" class="">das@apple.com</a>> wrote:</div><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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)</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">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<span class="Apple-converted-space"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md</a>). 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. </div></div></div></blockquote><div><br class=""></div>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? ;)</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: SFMono-Light; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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)</div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div><br class=""></div><div>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).</div><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: SFMono-Light; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">So, what’s the sensible default you had in mind that won’t fail for a large portion of use cases? Safety is an important design point in an API surface and making these distinctions clear to developers is absolutely critical to achieving that goal.</div></div></blockquote><div class=""><br class=""></div><div class="">The default clock depends on the context of what you’re doing. If I’m using DispatchQueue.after, I would say the monotonic clock is a reasonable default. Typically you’re going to be scheduling short fire-once things like performing an animation after a second or two (at the most). In that case, system sleep isn’t an issue - even on iOS where the user can lock the screen at any moment; your long-running alarm that crosses sleep events will still fire, it just won’t fire *immediately* upon wake.<span class="Apple-converted-space"> </span></div></div></div></blockquote><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Nothing in the API says it must be used only for "short fire-once things"</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">The problem with the monotonic clock isn’t about firing at wake, but about pushing the fire time out by the amount of time asleep.</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">If you are using this to implement e.g. a calendaring meeting reminder alarms, you are not going to be happy if your reminder is late by the amount of time that your device happened to put its cpu to sleep for many short intervals for power management reasons…</div></div></blockquote><div class=""><br class=""></div><div class="">No, nothing in the API does say that, but in this context I believe it’s the most commonly wanted thing and would be a reasonable default.</div><div class=""><br class=""></div><div class="">If you are implementing calendar reminders using dispatch_after in an application which can be suspended at any moment, you’re using the wrong API pure and simple. On Linux, you might be able to guarantee your app won’t be suspended so this strategy could work for you, but the API you use must be appropriate to the platform. If you can’t make that guarantee (e.g. On iOS), you should look for an alternative, such as the local notifications API, which is designed for exactly this.</div><br class=""><blockquote type="cite" class=""><div class=""><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="">iOS in general makes a point not to offer guarantees about what will happen to your app if it ever goes in to the background, and offers alternative backgrounding and local notification APIs instead.</div></div></div></blockquote><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">this API isn’t just designed for iOS Apps but for system programming in general, on any platform.</div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></div></blockquote><div class=""><br class=""></div><div class="">No, but as above, the API you use must be appropriate for the platform. We shouldn’t worry about people on iOS using dispatch_after for calendar notifications. Those people will run in to all kinds of headaches anyway, asking them to be explicit about which clock they use is pretty fair IMO. I would say it might even help them…</div></div></div></blockquote></div><div><br class=""></div><div>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.</div><div><br class=""></div><div>We hence don’t think that what you’re asking for is serving developers.</div><div><br class=""></div><div>also note that the C API works that way for a long time:</div><div><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div>dispatch_after(dispatch_time(DISPATCH_TIME_NOW, …), …)</div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div>dispatch_after(dispatch_walltime(DISPATCH_TIME_NOW, …), …)</div></blockquote><div><br class=""></div><div>to me it’s visually similar to:</div><div><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div>q.asyncAfter(deadline: .now() + …) …</div><div>q.asyncAfter(wallDeadline: .now() + …) …</div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div><br class=""></div><div>-Pierre</div><br class=""></body></html>