dispatch_get_context, dispatch_set_context are not around simply in the absence of blocks. They're just as useful as the queue-specific data APIs as they have thread-specific storage. Zach Waldowski [email protected] On Thu, May 12, 2016, at 08:50 PM, Pierre Habouzit via swift-evolution wrote: >> 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 <swift- >>> [email protected]> wrote: >>> >>>> >>>> On May 10, 2016, at 11:52 PM, Jacob Bandes-Storch via swift- >>>> evolution <[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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
