> DispatchQueue.async(execute:) and DispatchQueue.sync(execute:)
> --------------------------------------------------------------
> The lack of verb in the base name bothers me. The API Design Guidelines say
> “methods 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.
>
> 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(_:)?
That feels a little redundant to me. It's worth remembering that the API
Guidelines are a means of creating clear APIs, not an end in themselves. It's
okay to deviate a little if you get a better result.
However, I could see us borrowing (and slightly modifying) terminology from
Core Data:
queue.perform { … }
queue.performAndWait { … }
Compared to the status quo, this is clearer, a better fit for the guidelines,
and better at penalizing the disfavored API.
> 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:_:).
Yeah, I gave a talk about the renaming on Saturday and somebody noted that
`when` reads poorly here. Fortunately, `queue.perform(after: .now() + 0.5)`
reads pretty well too. :^)
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
