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

[Jacob Bandes-Storch]

        * 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
not-so-+1:

- synchronously()'s block parameter should be @noescape. Perhaps more
arguably, it should have a generic return type and rethrows, like
autoreleasepool
now does
<https://github.com/apple/swift-evolution/blob/master/proposals/0061-autoreleasepool-signature.md>
.

- 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"
keys.)


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

Yes.

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

Getting there.

        * 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.

Jacob

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
> here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
>         https://lists.swift.org/mailman/listinfo/swift-evolution
>
> 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
>
>         https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160510/9a011dbd/attachment.html>