> On May 12, 2016, at 10:49 AM, Jose Cheyo Jimenez via swift-evolution > <[email protected]> wrote: > > >> On May 11, 2016, at 7:09 AM, Matt Wright via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> >>> On May 10, 2016, at 11:52 PM, Jacob Bandes-Storch via swift-evolution >>> <[email protected] <mailto:[email protected]>> 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.
- dispatch_retain/dispatch_release() that are obviously useless in swift - dispatch_get_context/dispatch_set_context() and dispatch_set_finalizer_f() because it has no ownership semantics and were only there for ports where you had no blocks (as in closures) - dispatch_once() and dispatch_once_f() because global initializers do that job in swift - in general all _f variants, which would be really awkward to use from swift anyway - anything that was deprecated in previous releases (dispatch_debug, dispatch_debugv, dispatch_get_current_queue) as per usual swift import rules -Pierre
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
