> On 13 Jul 2016, at 21:04, Pierre Habouzit <phabou...@apple.com> wrote:
>
>> On Jul 13, 2016, at 11:42 AM, Karl via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>>
>>> On 13 Jul 2016, at 19:59, Daniel A. Steffen <d...@apple.com
>>> <mailto:d...@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
