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

[Pierre Habouzit]

> On May 12, 2016, at 10:49 AM, Jose Cheyo Jimenez via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On May 11, 2016, at 7:09 AM, Matt Wright via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>> On May 10, 2016, at 11:52 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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. 

- 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160512/b5e3506e/attachment.html>