[swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions
jtbandes at gmail.com
Wed May 11 01:52:53 CDT 2016
* What is your evaluation of the proposal?
I'm generally in favor of a modernized API overlay like this (and I've
written something like it
<https://gist.github.com/jtbandes/a5ce62019585dd4f998e> myself, albeit much
simpler), but I'm hoping this proposal can go through another round or two
of discussion/bikeshedding/revision before approval.
(Small note: I'm really happy about the strong-typed-ness of the Source
subclasses, e.g. how mergeData is only available for Add/Or.)
In no particular order, here are some things on which I'm unclear, or
- synchronously()'s block parameter should be @noescape. Perhaps more
arguably, it should have a generic return type and rethrows, like
- The names asynchronously(execute:) and synchronously(execute:) don't seem
to fit with any API guidelines I'm aware of. Did you consider including the
verb in the method name? (And I'm guessing that "func
synchronously(work:...)" is meant to be "func synchronously(execute
work:...)"?) As another bikeshed-item, I'd vote for
"Data.init(withoutCopying:...)" rather than "(bytesNoCopy:...)", and
perhaps whenDone() instead of notify().
- Are DispatchWorkItemFlags meant to overlay dispatch_block_flags? It would
be nice to explicitly list these in the proposal.
- Are functions like dispatch_barrier_sync totally gone in favor of passing
a .barrier flag? It would be nice to explicitly state this in the proposal.
- I echo Austin's concerns about subclassability. I think it would be
dangerously misleading if the classes were subclassable from user code,
even if it didn't work properly.
- What of the APIs provided on Semaphore and Group objects? I'd like to see
these before I vote for the proposal.
- What will dispatch_set_target_queue's replacement look like look like?
- What about dispatch_once?
- Why use class funcs for the Source initializers, rather than an init on
each individual subclass?
- Since DispatchSpecificKey is an object now, is there any concern with the
object being allocated at the same address as an old, since-deallocated,
object? (This might cause user confusion if both were used as "different"
* Is the problem being addressed significant enough to warrant a
change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
Medium-quick reading of this proposal. I've thought about this issue a good
deal in the past, though.
On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:
> Hello Swift community,
> The review of "SE-0088: Modernize libdispatch for Swift 3 naming
> conventions" begins now and runs through May 17. The proposal is available
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
> or, if you would like to keep your feedback private, directly to the
> review manager.
> What goes into a review?
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
> More information about the Swift evolution process is available at
> Thank you,
> -Chris Lattner
> Review Manager
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution