[swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions
Daniel A. Steffen
das at apple.com
Fri May 13 00:54:07 CDT 2016
> On May 12, 2016, at 22:29, Zach Waldowski via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>
> 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.
dispatch_get_context and dispatch_set_context are per-object storage of a single word, there is no connection to threads.
there are many problems with this API including the lack of synchronization between getters and setters and ill-defined ownership semantics (e.g. a setter replacing an already set context leaks the previous value).
On queues this API has been subsumed by the getSpecific/setSpecific API which does not have these problems, for other classes we felt that its drawbacks and problems outweighed the benefits that it provided.
Daniel
>
> Zach Waldowski
> zach at waldowski.me <mailto:zach at waldowski.me>
>
>
> 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 <swift-evolution at swift.org <mailto: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
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160512/4f3b5b58/attachment-0001.html>
More information about the swift-evolution
mailing list