<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 13 Jul 2016, at 18:47, Anthony Chivetta via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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 &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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. &nbsp;Here’s the current behavior (on Darwin, not sure what Linux currently implements):</div><div class=""><br class=""></div><div class="">&nbsp; - 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="">&nbsp; - DispatchWillTime is a clock that tracks as a UTC clock would, generally moving ahead during sleep, but is *not* monotonic. &nbsp;It can move forward, backward, upside down, whatever it wants. &nbsp;And frequently it will.</div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>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 style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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. &nbsp;DispatchTime, the bug is that if the user locks their device and it falls asleep the alarm won’t fire upon wake. &nbsp;DispatchWallTime, if the device realizes its clock is ahead or behind the “real” time the elapsed duration won’t be what you expect. &nbsp;(Should we have a third that works for the tea timer? Absolutely…)</div><div class=""><br class=""></div></div></blockquote><div><br class=""></div><div>Do you think that is adequately expressed in the API?&nbsp;</div><div><br class=""></div><div>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><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">So, what’s the sensible default you had in mind that won’t fail for a large portion of use cases? &nbsp;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><br class=""></div><div>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. 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><br class=""></div><div>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><br class=""></div><div>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><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">(Of course, Foundation.Timer gets all of the above horribly wrong, IMHO. &nbsp;We should fix that too…)</div><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">&nbsp;(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. &nbsp;At least, not in the POSIX sense. &nbsp;So let’s not call it that. &nbsp;(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. &nbsp;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><br class=""></div><div>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><br class=""></div><div>Karl</div></div><br class=""></body></html>