> On May 11, 2016, at 7:09 AM, Matt Wright via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On May 10, 2016, at 11:52 PM, 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. > > Both of these are present in the changes I have for this proposal. The former > point is a mistake in my proposal text, the latter is an unfortunate > oversight on my part in putting together the proposal document. > >> - 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? > > We did. Of the number of names that we discussed, none of them were perfect. > sync/async are common in other languages but don’t fit the general direction > of the Swift 3 naming conventions. Using `dispatchAsynchronously` is an > extremely long method name, even more so than `asynchronously`. `perform` > does not capture the sync/async nature of the calls particularly well, > compared to DispatchWorkItem where `perform` immediately executes the block. > >> (And I'm guessing that "func synchronously(work:...)" is meant to be "func >> synchronously(execute work:...)”?) > > Right. > >> As another bikeshed-item, I'd vote for "Data.init(withoutCopying:...)" >> rather than "(bytesNoCopy:...)", and perhaps whenDone() instead of notify(). > > Here the init() functions closely mirror Data from Foundation, the > Objective-C class is toll-free bridged to NSData and we desired a close match > to the Foundation Swift API. `notify` is Dispatch-only API though, I’ll go > think over that one. > >> - Are DispatchWorkItemFlags meant to overlay dispatch_block_flags? It would >> be nice to explicitly list these in the proposal. > > The dispatch_block_* API is completely superseded by DispatchWorkItem in the > proposal. DispatchWorkItemFlags is the equivalent to dispatch_block_flags. > >> - 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. > > Yes, you can supply .barrier to either `synchronously` or `asynchronously`, > or create a DispatchWorkItem as a barrier item. Where possible the multiple > variants of a class (dispatch_async, dispatch_barrier_async, etc) are > collapsed into a single method with default arguments. > >> - 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. > > Building at compile time will fail. So you wouldn’t get very far trying to > use them, I plan to investigate adding `final` here (it’s only absent for > technical reasons, as the classes originate from Objective-C). > >> - What of the APIs provided on Semaphore and Group objects? I'd like to see >> these before I vote for the proposal. > > These would be transformed similarly, I will include them when updating the > proposal. > > class DispatchSemaphore : DispatchObject { > > > init(value: Int) > > func wait(timeout: DispatchTime = default) -> Int > > func wait(walltime timeout: DispatchWalltime) -> Int > > func signal() -> Int > > } > > class DispatchGroup : DispatchObject { > > init() > > > func wait(timeout: DispatchTime = default) -> Int > > func wait(walltime timeout: DispatchWalltime) -> Int > > func notify(queue: DispatchQueue, block: () -> Void) > > func enter() > > func leave() > > } > > >> - What will dispatch_set_target_queue's replacement look like look like? > > extension DispatchObject { > > > func setTargetQueue(queue: DispatchQueue?) > > } > >> >> - What about dispatch_once? > > Removed. Swift already has lazy initialisation at the language level, > dispatch_once is neither needed nor safe in Swift. Hi Matt, What other API would be removed ? Could the proposal be updated with the API that will not be reachable from the swift wrapper? Thank you. > >> - Why use class funcs for the Source initializers, rather than an init on >> each individual subclass? > > Implementation limitations. The “subclasses" are protocols would be > introduced in order to attain a level of type safety around DispatchSource. > We felt this was a significant enough improvement that it was worth including > even with this implementation wart. > >> >> - 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.) > > The intention, though something that cannot be enforced, is that > DispatchSpecificKey would be a global static object. I’d be interested if > anyone has a pattern that more throughly enforces the allocation pattern > required by the underlying API. > >> >> >> * 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 <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution