Hey Jacob, I agree with you that there are some unanswered questions and areas we would need some more polish on, but libdispatch was a bit unwieldy in Objective-C already and when used as is in Swift code it looks to be even less user friendly and not because it has to, but because of a lack of proper improvements such as the one described here.
I strongly hope we can get this in time for Swift 3... (not given up on cleaner dispatching rules for protocols and protocol extensions, but that's another story :)). Sent from my iPhone > On 11 May 2016, at 07:52, Jacob Bandes-Storch via swift-evolution > <swift-evolution@swift.org> wrote: > > > * 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 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. > > - 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@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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
