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

[Matt Wright]

> On Jul 14, 2016, at 3:44 AM, Karl <razielim at gmail.com> wrote:
> 
> 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> wrote:
>>> 
>>> On Jun 21, 2016, at 5:28 PM, Matt Wright <mww at apple.com> wrote:
>>>>> On Jun 20, 2016, at 5:50 PM, Darren Mo via swift-evolution <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!
>>> 

To somewhat follow up on Darren’s suggestion: after internal discussion, moving `.after` into `.async` isn’t as good an idea as I had hoped. The behaviour of `.after`, both in execution and performance, differ substantially from `.async`.

> 
> 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.

I don’t think this topic needs forking and rehashing on this thread too.

> 
>>>>> 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.

This was covered somewhat during initial evolution, after discussion with the core team we decided to keep the Dispatch prefix. Several of the class names make more contextual sense with a Dispatch prefix, where they would not otherwise; Queues, Groups, etc. Secondly, Dispatch is implicitly imported by Foundation and we feel that keeping the prefix is clearer to the developer what it is you’re actually using.

> 
> 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