> On 13 Jul 2016, at 19:59, Daniel A. Steffen <[email protected]> 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). 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. > 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. >> >>> 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. >> >> 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. > > Nothing in the API says it must be used only for "short fire-once things" > > 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. > 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… 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. 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. > >> 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. > > this API isn’t just designed for iOS Apps but for system programming in > general, on any platform. > 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... >> >> 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. >> >> 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. > > yes this was intentionally designed to accommodate additional clocks > >> >>> >>> (Of course, Foundation.Timer gets all of the above horribly wrong, IMHO. >>> We should fix that too…) >>> >>>> (the monotonic and walltime clocks are actually split at the type level) >>> >>> 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.) >>> >>>> 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. >>> >>> 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. >>> >> >> 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. >> >> Karl >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
