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

Fri May 13 00:29:16 CDT 2016

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
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> wrote:
>>
>>
>>> On May 11, 2016, at 7:09 AM, Matt Wright via swift-evolution <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> 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
> 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/ec804f2b/attachment.html>