[swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Guillaume Lessard glessard at tffenterprises.com
Wed May 11 12:58:05 CDT 2016


> * What is your evaluation of the proposal?

I like it; with the fixes already mentioned by Matt, I have some extra comments and questions:

- It would be nicer to use the Dispatch namespace, rather than prefix everything.
- It seems unfortunate to have 11 DispatchSourceSUBTYPE protocols at top level.

- DispatchQueue initialization is only implied; its initializer(s) should be described

- dispatch_queue_get_qos_class and dispatch_set_target_queue are not mentioned.
- dispatch_after and dispatch_apply aren’t mentioned either.

- dispatch_suspend and dispatch_resume; would these be available on DispatchObject or just some of its subclasses?

- dispatch_set_context, dispatch_get_context, and dispatch_set_finalizer; do those stay or disappear?

- please describe the api related to dispatch_io_t


Other comments:

- Queue.{synchronously,asynchronously} are odd names for Swift. Since the labels include a verb, I feel they’re fine, though.
The suggestion of `dispatchSynchronously` is too long; `dispatchSync` is not better than the adverb; just `sync` is unclear (the verb would be synchronize, which is wrong.)


> * Is the problem being addressed significant enough to warrant a change to Swift?

Yes. Using libdispatch with the old api is okay, but weird.

> * Does this proposal fit well with the feel and direction of Swift?

Mostly; I’m sure it will after the feedback.

> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I’ve been a libdispatch user in Swift since the beginning: I’ve formed opinions. I read the proposal carefully.

Guillaume Lessard



More information about the swift-evolution mailing list