[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