[swift-evolution] [SE-0088] Dispatch API names

[Karl]

I just discovered this thread by accident - thank the Lord I’m not the only one who feels like this about the new Dispatch API!

> On 8 Jul 2016, at 04:16, Darren Mo via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Should I create a bug report for changing `DispatchQueue.after` and `DispatchSource.read`?
> 
> Darren
> 
>> On Jun 21, 2016, at 7:35 PM, Darren Mo <darren.mo at me.com <mailto:darren.mo at me.com>> wrote:
>> 
>> On Jun 21, 2016, at 5:28 PM, Matt Wright <mww at apple.com <mailto:mww at apple.com>> wrote:
>>>> On Jun 20, 2016, at 5:50 PM, Darren Mo via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> DispatchQueue.after(when:execute:)
>>>> ----------------------------------
>>>> This one simply doesn’t read grammatically. For example, `queue.after(when: .now) { … }` becomes “queue, after when now …”. Since dispatch_after is semantically just an extended version of dispatch_async (I think), we can name this .executeAsync(after:_:).
>>> 
>>> I replied to messages out of order but I agree, moving `.after` onto .async seems like the more natural place for it to live.
>> 
>> Yay!
>> 

So long as the signature then reads grammatically - I had a little battle about this yesterday: http://comments.gmane.org/gmane.comp.lang.swift.evolution/23867

To summarise:
- “after” should take a plain time interval
- “deadline” is just simply the wrong word - means something else entirely
- since we can’t take an interval without a clock, we need a default clock
- but the nuances with those clocks are very important and a source of subtle bugs, so we should also ask for precise intention

=> I think we should split DispatchQueue.after() based on clock type. This would allow us to provide a default value for “now”, meaning we can also accept plain time intervals, as the resulting API would be explicit about the clock nuances that are often overlooked.

>>>> DispatchSource subclass names
>>>> -----------------------------
>>>> Why is it DispatchSourceMemoryPressure instead of MemoryPressureDispatchSource? I don’t think I’ve ever seen subclass names where the superclass part is at the beginning of the name.
>>> 
>>> I’m not so keen to remove the Dispatch prefix from the front of the source types, given that we avoided doing that for the remainder of the module.
>> 
>> What is the rationale for keeping the Dispatch prefix anyways? (I couldn’t find it in the archives.)

I would also like to know this. I really don’t like typing Dispatch... every time. It doesn’t seem to be very forgiving with code-completion.

Also, dispatch code tends to contain a fair amount of nested closures. It’s nice to keep the line lengths short in that case.

Karl


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160714/ff45f856/attachment.html>