<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=""><font face="Menlo" class="">SE-0088 was accepted with revisions a month ago. However, some of the APIs just don’t feel right to me. I’ve only used DispatchQueue and DispatchSource so far, so I will only comment on those.
</font><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><span class=""><font face="Menlo" class="">DispatchQueue.async(execute:) and DispatchQueue.sync(execute:)</font></span></div><div class=""><span class=""><font face="Menlo" class="">--------------------------------------------------------------</font></span></div><div class=""><font face="Menlo" class="">The lack of verb in the base name bothers me. The API Design Guidelines say “methods&nbsp;with side-effects should read as imperative verb phrases”. You could argue that the argument label “execute” serves as the verb. However, .async and .sync are most commonly used with trailing closures where the argument label is not present.</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class="">This issue was brought up during the review, but I did not see it being addressed. Why not name the methods something like .executeAsync(_:) and .executeSync(_:)?</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><span class=""><font face="Menlo" class="">DispatchQueue.after(when:execute:)</font></span></div><div class=""><span class=""><font face="Menlo" class="">----------------------------------</font></span></div><div class=""><font face="Menlo" class="">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:_:).</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class="">DispatchSource subclass names</font></div><div class=""><font face="Menlo" class="">-----------------------------</font></div><div class=""><font face="Menlo" class="">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.</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class="">DispatchSource factory methods</font></div><div class=""><font face="Menlo" class="">------------------------------</font></div><div class=""><font face="Menlo" class="">e.g. DispatchSource.read(fileDescriptor:queue:). The API Design Guidelines mandate that factory&nbsp;methods begin with the prefix “make”. Indeed, DispatchSource.read might mislead&nbsp;people to think that a read will be performed by this method. A better name would be .makeReadSource(fileDescriptor:queue:).</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class="">And why are these factory methods on DispatchSource instead of initializers on the&nbsp;subclasses? ReadDispatchSource.init(fileDescriptor:queue:) would be way clearer.</font></div></body></html>