> * 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
