<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 13, 2016, at 10:08, 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: 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;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On 13 Jul 2016, at 18:47, Anthony Chivetta 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 class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><br class=""></div></div><div class=""><blockquote type="cite" class=""><div class="">On Jul 13, 2016, at 9:18 , 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 class="">nuances about the clock (basically, whether or not it pauses during system sleep) are edge-cases which can be handled for the majority of users with a sensible default value</div></div></blockquote><div class=""><br class=""></div>I’m going to stay out of the naming part of the conversation for the moment and just address this point…</div><div class=""><br class=""></div><div class="">I disagree strenuously: it’s a super important distinction that is frequently the cause of subtle but bad bugs!</div><div class=""><br class=""></div><div class="">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):</div><div class=""><br class=""></div><div class=""> - DispatchTime is a clock that only advances forward and tracks the amount of time the computer is awake.</div><div class=""><br class=""></div><div class=""> - 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.</div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">Yeah I know, I don’t think I got the clocks wrong. I forgot that the UTC clock can move around, but yeah, of course it can; fair enough.</div><br class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">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…)</div><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Do you think that is adequately expressed in the API? </div><div class=""><br class=""></div><div class="">I don’t, and I believe the current system of type-based overloads is not a good way to ensure people don’t accidentally use the wrong one. Maybe we should rename the methods which take each type to make it more of a conscious decision (I’m happy with that, because in that case we definitely have reasonable default values 😎)</div></div></div></blockquote><div><br class=""></div><div>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><br class=""></div><div>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=""><blockquote type="cite" class=""><div class=""><div 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;" class=""><br class=""><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. </div></div></div></blockquote><div><br class=""></div><div>Nothing in the API says it must be used only for "short fire-once things"</div><div><br class=""></div><div>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>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><br class=""><blockquote type="cite" class=""><div class=""><div 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;" class=""><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><br class=""></div><div>this API isn’t just designed for iOS Apps but for system programming in general, on any platform.</div><br class=""><blockquote type="cite" class=""><div class=""><div 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;" class=""><div class=""><br class=""></div><div class="">And again, if you considered it and really need that timer to fire immediately if the system dozed off for a little bit in-between, that’s available as an explicit consideration.</div><div class=""><br class=""></div><div class="">I could see how there’s an argument for a third type of timer; it’s obviously a complex topic, and we should provide a reasonable default if possible; even if that’s a platform-specific alias.</div></div></div></blockquote><div><br class=""></div><div>yes this was intentionally designed to accommodate additional clocks</div><br class=""><blockquote type="cite" class=""><div class=""><div 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;" class=""><br class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">(Of course, Foundation.Timer gets all of the above horribly wrong, IMHO. We should fix that too…)</div><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""> (the monotonic and walltime clocks are actually split at the type level)<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">DispatchTime is not a monotonic clock. At least, not in the POSIX sense. So let’s not call it that. (Linux’s failure to implement POSIX correctly notwithstanding.)</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Novice users are not going to understand what’s going on here - I expect most of them to default to the more generic-sounding “DispatchTime” without any idea of the implications of this.</div></div></blockquote><div class=""><br class=""></div><div class="">If that’s the case, that’s a good argument for forcing users to make the choice in an even more obvious and explicit way. Not making it easier to use one or the other when they’ll likely get it wrong.</div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">Yes, that was the motivation behind saying we should merge them - while writing it, it feels like you’re on a bit of a tightrope - one slip and this code could mean something very different.</div><div class=""><br class=""></div><div class="">Karl</div></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;"><span 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; float: none; display: inline !important;" class="">_______________________________________________</span><br 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;" class=""><span 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; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br 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;" class=""><a href="mailto:swift-evolution@swift.org" 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;" class="">swift-evolution@swift.org</a><br 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;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" 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;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></body></html>