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


(Chris Lattner) #1

Hello Swift community,

The review of "SE-0088: Modernize libdispatch for Swift 3 naming conventions" begins now and runs through May 17. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager


(Austin Zheng) #2

I think this is a great idea and a great proposal. GCD is already a
powerful, elegant tool available to Swift users, and this makes it feel
even more Swift-like.

Feedback/questions:
- Is there a use case for user subclassing of a queue type? If not, should
they be final?
- Is there a reason to use class methods rather than static methods for the
queue types? I was under the impression that static methods would be
preferred unless a good reason exists to dispatch upon metatype.
- Nit: "DispatchWallTime" is spelled "DispatchWalltime" (lowercase 't') in
the code samples.
- Is it allowed/technically possible for non-stdlib code to use
_ObjectiveCBridgable?

Best,
Austin

···

On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0088: Modernize libdispatch for Swift 3 naming
conventions" begins now and runs through May 17. The proposal is available
here:

https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of Swift.
When writing your review, here are some questions you might want to answer
in your review:

        * What is your evaluation of the proposal?
        * Is the problem being addressed significant enough to warrant a
change to Swift?
        * Does this proposal fit well with the feel and direction of Swift?
        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jacob Bandes-Storch) #3

* 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
<https://gist.github.com/jtbandes/a5ce62019585dd4f998e> 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
<https://github.com/apple/swift-evolution/blob/master/proposals/0061-autoreleasepool-signature.md>
.

- 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? (And I'm guessing that "func
synchronously(work:...)" is meant to be "func synchronously(execute
work:...)"?) As another bikeshed-item, I'd vote for
"Data.init(withoutCopying:...)" rather than "(bytesNoCopy:...)", and
perhaps whenDone() instead of notify().

- Are DispatchWorkItemFlags meant to overlay dispatch_block_flags? It would
be nice to explicitly list these in the proposal.

- 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.

- 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.

- What of the APIs provided on Semaphore and Group objects? I'd like to see
these before I vote for the proposal.

- What will dispatch_set_target_queue's replacement look like look like?

- What about dispatch_once?

- Why use class funcs for the Source initializers, rather than an init on
each individual subclass?

- Since DispatchSpecificKey is an object now, is there any concern with the
object being allocated at the same address as an old, since-deallocated,
object? (This might cause user confusion if both were used as "different"
keys.)

        * Is the problem being addressed significant enough to warrant a
change to Swift?

Yes.

        * Does this proposal fit well with the feel and direction of Swift?

Getting there.

        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

Medium-quick reading of this proposal. I've thought about this issue a good
deal in the past, though.

Jacob

···

On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0088: Modernize libdispatch for Swift 3 naming
conventions" begins now and runs through May 17. The proposal is available
here:

https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of Swift.
When writing your review, here are some questions you might want to answer
in your review:

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Drew Crawford) #4

I'm one of the largest dispatch-on-linux users right now. In fact, I'm reasonably sure I'm THE largest. I have an application in production that uses some 400 dispatch calls.

On Linux, I'm running Swift 3 in production, essentially because Dispatch/Linux in 2.2 does not even exist. On OSX/iOS, I compile the same codebase with Swift 2.2, because that's the version that's released, and using released software is a sane thing to do.

This proposal places me in the uncomfortable situation of trying to somehow smooth out a truly MASSIVE API delta with #if. And that's not going to happen. Realistically, what I will do is create some kind of FrankenSwift that either backports the new API to Swift 3 or the old API to Swift 2. And that is a ton of work, really stupid work, and I would infinitely prefer to spend that time doing something actually useful to the world. To be clear, I don't fear migration; what I fear is the heisenmigration, where one of my platforms must migrate, and the other ones can't.

More broadly, I am concerned about the direction the language is going where we do not even have working libraries yet and already we are doing sweeping API changes to them. I suspect this is motivated by a fundamentally incorrect premise–the premise that because it's not released yet, we can get away with it. When actually that's backwards: we can get away with breaking changes later, but if we do them now we will ruin everything. Let me explain.

Right now, Linux Swift programmers exist. And they need to be able to solve ordinary problems, like writing a string to a file, or spinning up a background thread. And I do mean: sometime before Late 2016. No amount of telling them "don't do that, it's not released" is going to stop this. The only question is whether upstream is going to be the repo that solves their problem, or whether they go to solve the problem somewhere else. Because when they go somewhere else, they invest there.

Increasingly, because upstream is not interested in the problem, I am seeing Linux folk go solve the problem somewhere else. Just counting the projects I'm personally aware of, there are 3 foundation alternatives and 1 package manager alternative. All because upstream has no sane path to e.g. reading a file on disk in the kind of timeframe working programmers actually need to do it in.

What we *should* be doing is creating libraries that *work*, *releasing them*, and then we can do as much API Disneyland as we want without harassing the working programmer.

1. If we're out of bugs to fix, why not release? Then folks like me can get off the snapshot treadmill and we won't be annoyed by massive API delta until we can do it all at once, which is (relatively) easy.
2. If we're not out of bugs to fix, why not work on them, and then release, and then come back to this?
3. Since Swift 3 will have a stable ABI, why not ship both libdispatch2 and libdispatch3 and let the programmer plan her own migration? I'm not even sure the stable ABI part is relevant, since Dispatch is almost entirely C.

All of these are saner alternatives to the proposal, and all of them achieve the stated goal (e.g. we still end up with happy modern APIs).

I don't mean to pick on this proposal specifically, I agree with the need to modernize the API surface area. But if we continue to do breaking changes first and releases later I'm concerned about where the early adopters will get pushed to.

Drew


(James Dempsey) #5

My main piece of feedback is that the method names synchronously() and asynchronously() don’t conform to Swift 3 naming conventions for functions and methods:

"Name functions and methods according to their side-effects

  • Those without side-effects should read as noun phrases, e.g. x.distance(to: y), i.successor().

  • Those with side-effects should read as imperative verb phrases, e.g., print(x), x.sort(), x.append(y).”

The method names

  synchronously()
  asynchronously()

are both adverbs, not noun phrases or verb phrases.
These methods have side effects, so each name should have a verb in it to make it a verb phrase.

Since these are the methods where you actually dispatch a block into a queue

dispatchSynchronously()
dispatchAsynchronously()

would include the verb in the name of the methods.

Since the majority of uses of GCD is for async dispatch, you could possibly make async the ‘default' and have the two names be:

dispatch() // Dispatches Asynchronously
dispatchSynchronously()

You could potentially make the case that ’sync’ and ‘async’ are well-known terms in their own right, not just abbreviations, and use them instead of the longer words:

dispatchAsynch()
dispatchSynch()

James

···

On May 10, 2016, at 9:39 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0088: Modernize libdispatch for Swift 3 naming conventions" begins now and runs through May 17. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chéyo Jiménez) #6

I like the idea.

I didn't see these function but I am not sure if they are part of that library.

dispatch_queue_create("uniqueName", DISPATCH_QUEUE_CONCURRENT)

dispatch_apply(someInt, queue){....

···

On May 10, 2016, at 9:39 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0088: Modernize libdispatch for Swift 3 naming conventions" begins now and runs through May 17. The proposal is available here:

   https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

   https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

   * What is your evaluation of the proposal?
   * Is the problem being addressed significant enough to warrant a change to Swift?
   * Does this proposal fit well with the feel and direction of Swift?
   * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
   * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

   https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Guillaume Lessard) #7

* What is your evaluation of the proposal?

I like it; with the fixes already mentioned by Matt, I have some extra comments and questions:

- It would be nicer to use the Dispatch namespace, rather than prefix everything.
- It seems unfortunate to have 11 DispatchSourceSUBTYPE protocols at top level.

- DispatchQueue initialization is only implied; its initializer(s) should be described

- dispatch_queue_get_qos_class and dispatch_set_target_queue are not mentioned.
- dispatch_after and dispatch_apply aren’t mentioned either.

- dispatch_suspend and dispatch_resume; would these be available on DispatchObject or just some of its subclasses?

- dispatch_set_context, dispatch_get_context, and dispatch_set_finalizer; do those stay or disappear?

- please describe the api related to dispatch_io_t

Other comments:

- Queue.{synchronously,asynchronously} are odd names for Swift. Since the labels include a verb, I feel they’re fine, though.
The suggestion of `dispatchSynchronously` is too long; `dispatchSync` is not better than the adverb; just `sync` is unclear (the verb would be synchronize, which is wrong.)

* Is the problem being addressed significant enough to warrant a change to Swift?

Yes. Using libdispatch with the old api is okay, but weird.

* Does this proposal fit well with the feel and direction of Swift?

Mostly; I’m sure it will after the feedback.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I’ve been a libdispatch user in Swift since the beginning: I’ve formed opinions. I read the proposal carefully.

Guillaume Lessard


(Zachary Waldowski) #8

I don't recall seeing this proposal being pitched, and will also include
feedback of that stripe. Other responses inline.

  * What is your evaluation of the proposal?

Strong +1 in concept. I'm thrilled that this might happen.

+0 in current implementation. The proposal as written does not fully
conform to Swift API standards and does not fully address the current
surface area of the Dispatch API. I am concerned about losing features
and performance in our haste to make something "more Swifty."

  * Is the problem being addressed significant enough to warrant a change to Swift?

GCD's lack of integration with Swift — in part from the contusions the
API performs to be compatible with multiple languages at the API level

  * Does this proposal fit well with the feel and direction of Swift?

See other feedback below. Making changes in general is very much a good
idea. The APIs described do not always fit with Swift.

Separate from the APIs described herein, I am curious as to how much of
what needs to be done can or should be accomplished with apinotes and
the auditing facilities from SE-0044; it seems like

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

With additions, the resulting API would be a nice improvement and go a
long way to making Swift feel like it has high-level multithreading
support.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

In-depth study. I am an aggressive user of GCD in Swift.

···

On Wed, May 11, 2016, at 12:39 AM, Chris Lattner via swift-evolution wrote:

---

## Type Naming and Structures

The namespace of GCD is already "Dispatch". The existing types in the
proposal are translating from snake-case to camel-case; this isn't
wholly necessary to me as Swift doesn't suffer from C's global
namespace.

dispatch_object_t is obviously a problem in this respect, but its use is
already fuzzy in current GCD (incl. in other languages; its use in C is
equally sketchy). I almost feel like the features of dispatch_object_t
should be encapsulated in protocols. (resume, cancel, etc.)

## Missing API

- Group, IO, and Semaphore are missing in their entirety.
- Data needs init() to match the dispatch_data_empty constant.
- There's no equivalent to dispatch_data_copy_region(3), which can be
used to step through the contiguous buffers (among other things).
- The shared functionality of dispatch_get_context(1),
dispatch_set_context(2), and dispatch_set_finalizer_f(2) are not
modeled.
- The shared functionality of dispatch_suspend(2) and dispatch_resume(2)
are not modeled.
- Queue has no getters for its label and QoS class.
- Queues do not have any modeling for their target queue.
- Custom queues cannot be created.
- dispatch_barrier_sync(2) is not represented. (Neither is
dispatch_barrier_async(2), but this is modeled by
DispatchWorkItemFlags.)
- No equivalents for dispatch_apply(3), dispatch_main(),
dispatch_after(3).

## API comments

- WorkItem
   * DispatchQueue.asynchronously(_:qos:flags:work:) should have a
   variant that takes a DispatchWorkItem. With the API as written, you
   could not enqueue a work item then cancel it.
   * Flags should be a nested type.

- Source
   * The details section needs examples of at least one of the
   DispatchSource protocols (i.e., DispatchSourceFileSystemObject). The
   current approach would seem to lose API inherited from DispatchSource
   and DispatchObject unless those are modeled in some other way.
   * None of Source's APIs for assigning handlers, configuring timers,
   getting or merging the user-defined data, or cancelling are exposed.

- Data
   * Overall, the API does not encapsulate dispatch_data_t's status as a
   tree of discontiguous buffers. I'd expect at least to have API to
   have a view of the contiguous buffers, for instance.
   * The alternate forms of append(_:slight_smile: don't address management of the
   appended buffer's memory. Do they copy?
   * What are the COW semantics? In-place mutation is not thread-safe,
   whereas dispatch_data_t's current concatenation mechanisms are.
   * enumerateBytes(_:slight_smile: is unclear, as it is enumerating the underlying
   byte buffers.

- Queue
   * Queue.asynchronously(group:qos:flags:work:) and
   Queue.synchronously(_:slight_smile: does not conform to the API guidelines.
   * Queue.synchronously(_:slight_smile: should be @noescape. If possible,
   rethrowing and returning a <T> would be optimal.

Sincerely,
Zachary Waldowski
zach@waldowski.me


#9

Great, this is the libdispatch API that I’ve been dreaming about! I think it meshes well with the rest of Swift.

I am concerned about one thing though: the naming of the DispatchGroup methods synchronously/asynchronously.

They are hard to type correctly and ugly to look at.
sync/async are already well-established abbreviations in the tech industry.
They are adjectives without verbs, which goes against the API Design Guidelines.

I suggest sticking with the naming from the C API. For example:

let queue = …
queue.dispatchAsync {
  …
}

Cheers,
Darren

···

Hello Swift community,

The review of "SE-0088: Modernize libdispatch for Swift 3 naming conventions" begins now and runs through May 17. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager


(Anders) #10

1. What is your evaluation of the proposal?

+1 on the proposal’s objective - the swiftification of libdispatch is greatly appreciated. But I have reservation in the particulars of the proposal which are not in line with the API Design Guidelines.

For example, the `getSpecific(_:)` instance method in `DispatchQueue` is supposed to have no side effect like `NSObject.value(_:)` - just the retrieval of the value. But it somehow has a `get` suffix in the method name. Likewise, the class function `getSpecific(_:)` has a similar issue, but also not describing the behaviour precisely enough. Shouldn’t it be something like`specificForCurrentQueue(_:)`?

On the other hand, The adverbs used by `synchronously(_:)` and `asynchornously(_:)` in `DispatchQueue` fits nowhere in the guidelines, which (generally speaking) requires either imperative verb for functions having side-effects, or nouns for whatever else. Both functions clearly have a side effect on the queue, be it performing atomics or appending a block. IMO these should be verbs describing the behaviour, like `sync`, `synchronize`, `perform`, `performAndWait`, `schedule` or `run`.

queue.synchronously(block) // Is this grammatical? :-[

One may argue these adverbs are term of arts, but then why not simply use the short form (`async` and `sync`) from the C API, which is less verbose and could even possibly be implied as imperative verbs? Say `async` and `sync` as a shorthand of `asynchronize` * and `synchronise`.

* this doesn’t formally exist… yet.

2. Is the problem being addressed significant enough to warrant a change to Swift?
Yes. It should improve the experience of Swift developers, since libdispatch is heavily used in the Cocoa platforms. Autocompletion would have less noise, and the interface is cleaner to work with.

3. Does this proposal fit well with the feel and direction of Swift?
Yes.

4. If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
There are a few wrappers on GitHub that serves a similar purpose. But it is always great to have less dependency, especially for things that are essential like libdispatch.

5. How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
A focused study on the `DispatchQueue` renaming, since it would be the thing affecting me the most.

···

On 11 May 2016, at 12:39 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0088: Modernize libdispatch for Swift 3 naming conventions" begins now and runs through May 17. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Rod Brown) #11

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md

1. What is your evaluation of the proposal?

+1. While I am not qualified on the technical feasibility of this proposal, I do like it, and find it addresses a lot of annoyances using libdispatch within Swift Code. I agree that libdispatch feels awkward in Swift, especially where relating to dispatch_time_t, which this proposal addresses. As long as there are no significant technical hurdles, I support this proposal.

2. Is the problem being addressed significant enough to warrant a change to Swift?

Yes. The API is awkward to use from within Swift, and this will update it to optimise for Swift usage.

3. Does this proposal fit well with the feel and direction of Swift?

Yes. It brings libdispatch into line with other imported C APIs where functions have been added to structs, and other Swift-style modifications have been made.

4. If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have no experience with language features like this, except using libdispatch in C & Objective-C code, and I find it is actually easier to use in Objective C because it feels at home in a C world. In Swift, the issues with bridging, and the inconsistency with the language, make it somewhat more annoying to use.

5. How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick read, admittedly.


(Patrick Smith) #12

Oh man, this is fantastic!

* What is your evaluation of the proposal?

Great stuff, really brings dispatch into the world of Swift, and seems like it will not only make it more pleasant but better.

I have a couple of questions:
- Why is everything prefixed with Dispatch-, when you can surely rename the module, e.g. Dispatch.Queue, Dispatch.IO, or is the concern that this could clash? It just would be nice to write Queue directly. Group can become WorkGroup, to match WorkItem.
- Can static vars be added to DispatchQueue for all the concurrent QOS? So you can just write DispatchQueue.utility, or DispatchQueue.utilityConcurrent. I think this would increase their adoption.
- Is the .synchronously method able to have the @noescape attribute added?
- .asynchronously/.synchronously feels a bit long, will be interested to see what others think.
- Will DispatchData bridge to Foundation’s NSData, both in Darwin and Linux?

To be honest, I’d rather this become more of a standard alongside Swift than Foundation. I think you can build interesting modern APIs on top of this, such as for working with files and data, that get have concurrency and compatible with QOS by default.

For example, DispatchData supersedes NSData as Swift’s native ‘Data’, and extra methods that NSData has DispatchData gets in the same way Swift’s String gets some NSString methods. Eventually these methods are ported to DispatchData as extensions, or in new forms that make use of protocols and other Swift features.

* Is the problem being addressed significant enough to warrant a change to Swift?
Yes, I think this will increase adoption, and make it feel like an official part of Swift.

* Does this proposal fit well with the feel and direction of Swift?
Yes, this makes libdispatch modern and suitable for future applications.

* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Compared to using it in Objective-C, it seems to cover all the features.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
A good read.

···

On 11 May 2016, at 2:39 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0088: Modernize libdispatch for Swift 3 naming conventions" begins now and runs through May 17. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Dave Grove) #13

My personal opinions, as someone who is relatively new to Swift and
libdispatch, but has spent some time playing with them recently :wink:

   * What is your evaluation of the proposal?

Overall, I like the direction of the proposal. I think moving away from
the legacy C APIs will make libdispatch in Swift more accessible and
pleasant to use.

I would like to see more details on how the overlay will be implemented on
platforms without Objective-C. Specifically, since libdispatch is mostly a
C library, it seems to me that this would be a good opportunity to purge
Objective-C from the libdispatch implementation entirely and have a simpler
and more portable Swift + C implementation. That is what we have to do for
Linux, so let's eliminate some of the platform differences and do it
everywhere. However, that may be at odds with the "without adding runtime
overhead" objective of the proposal. I made an attempt earlier this spring
to get libdispatch's C structs to masquerade as Swift classes (instead of
Objective-C classes as they currently do when Objective-C is available). I
gave up because some of the implementation tricks used in libdispatch's
queues made it a fairly invasive change. However, others more skilled in
Swift+libdispatch might be able to pull it off. Is the implementation plan
to write a fairly thick Swift layer that wraps primitive C types, or is it
something else?

Echoing others, I would keep sync/async as names in the APIs. These are
well known terms that are used in many similar tasking libraries in other
languages; they are also familiar to current libdispatch users.

I would like to see a statically checkable distinction in the API between
Darwin-specific functionality and the APIs that are truly cross platform.
This mainly shows up in the DispatchSources portion of the API. Tag
methods of DispatchSource with availability macros or similar?

It seems overly verbose to prefix all the types with Dispatch....is this
really necessary?

   * Is the problem being addressed significant enough to warrant a

change to Swift?

From a Linux perspective, the existing Swift libdispatch API is badly

incomplete. The lack of Objective-C on Linux results in a poor quality
import of the dispatch headers. Something needs to be done in the Swift 3
time frame to fix this. We could get by with a less sweeping change than
this proposal, but something does need to be done.

Ideally, the new overlay would also be back-ported to Swift 2.2 to address
Drew's valid concerns about maintaining cross-platform code that uses
libdispatch during the transition from Swift 2.2 to Swift 3.

   * Does this proposal fit well with the feel and direction of Swift?

  Yes (but I am newish to Swift...).

   * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?

  It should get libdispatch in Swift to be roughly on par with the
integrated experience one gets from using tasking libraries in other modern
object-oriented languages with closures.

   * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

  Read proposal carefully. Have thought about the issues quite a bit
recently.

--dave


(Brent Royal-Gordon) #14

  * What is your evaluation of the proposal?

I'm overall in favor.

I agree with the others who say that `synchronously` and `asynchronously` are poor name choices. If we're going to deviate from the API guidelines, we should at least choose names which have other desirable properties, like brevity or matching existing terms of art. These names don't. I would prefer `sync` and `async`, or if necessary, `dispatchSync` and `dispatchAsync`.

I'm very impressed by the way the "specific" APIs have been translated to Swift, but I think the method names are wrong, particularly the `get` method. Ideally these would be a subscript, but we don't have generic subscripts yet. Failing that, I suggest using `specificValue(for key:)` and `setSpecificValue(_ value: for key:)`. I'm also worried about how this will interoperate with Objective-C: Will there be some way to smuggle one of the arbitrary Objective-C pointers for this API into Swift as a DispatchSpecificKey, or vice versa?

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes. libdispatch is pretty awkward even in Objective-C, let alone in Swift.

  * Does this proposal fit well with the feel and direction of Swift?

Yes.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

N/A.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading.

···

--
Brent Royal-Gordon
Architechies


(Dennis Weissmann) #15

1. What is your evaluation of the proposal?
+1 I think this is a big win for readability.

2. Is the problem being addressed significant enough to warrant a change to Swift?
Yes. dispatch is used nearly everywhere so many many projects would benefit from it.

3. Does this proposal fit well with the feel and direction of Swift?
Making the API more “swift" and feel more natural definitely is the direction Swift libraries are / should be going in.

4. If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Unfortunately not.

5. How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Read the proposal twice.

A little nitpick:

let item = DispatchWorkItem(qos: .qosUserInitiated) {
    print("Hello World")
}

I’d change the enum case from .qosUserInitiated to .userInitiated (maybe that’s just a typo since in the code example before uses .unspecified).

- Dennis

···

On May 11, 2016, at 6:39 AM, Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of "SE-0088: Modernize libdispatch for Swift 3 naming conventions" begins now and runs through May 17. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce


(Dan Appel) #16

Hello Swift community,

The review of "SE-0088: Modernize libdispatch for Swift 3 naming conventions" begins now and runs through May 17. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

Ok, I have mixed feeling about this proposal.

First, this is a huge breaking change, and it doesn’t really have to be one. The current SPM convention is to prefix C libraries with Lib. Following this convention, Dispatch (which is the C version) would be renamed to LibDispatch, and this new wrapper library would be called just Dispatch. With this setup, the old C api would still be there (under the module LibDispatch), which makes migration much easier. In the proposal, this issue is not addressed at all and it even says that all code using libdispatch would be affected. As it stands, that is not ok.

On a different issue in this proposal: I think that translating the C api into Swift ‘automagically’ is the wrong approach. There are many libraries right now that wrap the current libdispatch functions and provide a similar api, and I don’t think there’s any reason why this shouldn’t be done the same way. I would also argue that doing this links the Swift language to libdispatch in a way that isn’t necessary. For example, there is a library called Venice <https://github.com/VeniceX/Venice> which provides CSP (go-style concurrency) for Swift by wrapping a fork of the C library libmill, and it doesn’t do any magic importing of any sort. I don’t see a reason why libdispatch shouldn’t take the same approach.

Overall, I think the idea is good but some of the details are really lacking. As it stands, I would vote to reject this proposal and request revision, or reject it outright and suggest to use third-party wrappers around libdispatch (like the community is already doing).

Dan Appel


#17

Hello,

Does the proposal fixes the errors introduced by the latest May 9 snapshot ?

Since IUO are abolished (https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md) and pointer nullability is expressed using Optional (https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md), I get many errors as soon as I use libdispatch:

  let sem = dispatch_semaphore_create(0)
  dispatch_semaphore_wait(sem, …) // Error: Value of optional type not unwrapped
  dispatch_semaphore_signal(sem) // Error: Value of optional type not unwrapped

  let source = dispatch_source_create(…)
  dispatch_source_set_event_handler(source) { … } // Error: Value of optional type not unwrapped
  dispatch_source_set_cancel_handler(source) { … } // Error: Value of optional type not unwrapped
  dispatch_resume(source) // Error: Value of optional type not unwrapped

Of course, it's easy to fix. Still, the fix is usually adding a bang (!), because most apps prefer crashing when dispatch_semaphore_create or dispatch_source_create fails. And if I don't mind using bangs when it's the best solution, I can't be happy to see bangs everywhere.

In short: libdispatch is currently in its worst state ever :slight_smile:

Cheers to all,
Gwendal Roué

···

Le 11 mai 2016 à 06:39, Chris Lattner via swift-evolution <swift-evolution@swift.org> a écrit :

Hello Swift community,

The review of "SE-0088: Modernize libdispatch for Swift 3 naming conventions" begins now and runs through May 17. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Ben Rimmington) #18

<https://github.com/apple/swift-evolution/blob/master/proposals/
0088-libdispatch-for-swift3.md>

## Type Names

I was going to suggest unprefixed type names, but having to qualify both
`Dispatch.Data` and `Foundation.Data` would be an issue. If libdispatch
had originally been part of Foundation, you'd need prefixes anyway:

* DispatchQueue
* NotificationQueue
* OperationQueue

## Quality of Service

Should argument labels and type names match those in Foundation?

* qos: => qualityOfService:
* DispatchQoS => DispatchQualityOfService

Could there be a shared `Swift.QualityOfService` enum?

* QOS_CLASS_DEFAULT = 0x15
* NSQualityOfServiceDefault = -1

The `.unspecified` QoS is not defined in NSQualityOfService.
Would an optional QoS parameter (defaulting to nil) be better?

## Time

The `dispatch_time` function uses a nanoseconds delta, so the operator
overloads taking `seconds: Double` might be ambiguous at the call site.
You could try changing the associated value types of your enum.

enum DispatchTimeInterval {
    case      seconds(Double) // changed from `Int`
    case milliseconds(Int64)  // changed from `Int`
    case microseconds(Int64)  // changed from `Int`
    case  nanoseconds(Int64)  // changed from `Int`
}

let _ = DispatchTime.now + 3.5 // ambiguous?
let a = DispatchTime.now +      .seconds(3.5)
let b = DispatchTime.now + .milliseconds(3_500)
let c = DispatchTime.now + .microseconds(3_500_000)
let d = DispatchTime.now +  .nanoseconds(3_500_000_000)

Is the `DispatchTime.now` in your example a type property?

## Data

Should the `DispatchData.append` methods have `contentsOf:` labels?
Or could it conform to the RangeReplaceableCollection protocol?

## Queues

My suggestions for the async/sync methods:

* enqueue(...)
* enqueueAndWaitUntilFinished(...)

-- Ben


(plx) #19

  * What is your evaluation of the proposal?

+1 conceptually, some quibbles.

I agree with a few others that `synchronously` and `asynchronously` aren’t ideal; `dispatchSynchronously` or `dispatchSync` (or `performSync` or `performSynchronously`) all seem more-appropriate.

I understand the impetus behind having fewer core methods, but IMHO the `dispatch_barrier_sync` and `dispatch_barrier_async` calls ought to have direct equivalents here (even if they are just sodlib-supplied conveniences that call through to the unified method).

I also don’t see `dispatch_apply` here anywhere; intentional? Ideally it’d be @noescape, but handling `throw` / `rethrow` for that function in this case seems complicated.

This next one is subjective, but I find the placement of the group-related methods somewhat backwards vis-a-vis how I think of them in terms of the C-API.

EG: I think of `dispatch_group_async` as a “method” on a `dispatch_group`, so would’ve expected this:

class DispatchGroup : DispatchObject {

  // (actual name should match chosen name convention)
  func asynchronouslyDispatch(to queue: DispatchQueue, work: @convention(block) () -> Void)

  // (actual name should match chosen name convention)
  func notify(on queue: DispatchQueue, using block: @convention(block) () -> Void)

}

…(and presumably the API would have manual enter/leave/wait methods and so on exposed).

I don’t feel strongly here but bring it up in case others feel similarly.

I’m a little confused about the `DispatchSpecificKey<T>` class; is it anything more than a way to "smuggle in” a generic type parameter for the associated value?

Also on queue-specifics, what is our expected story if we have custom destructors? Subclass `DispatchSpecificKey`?

For things like `Int` specifics, I assume this API is storing auto-boxed values…? Is there any way to side-step if we use want to store an unsafe pointer? It’s not a big deal for me if we can’t under this API, TBH, but I’d at least like to see this API’s implementation and costs spelled-out more explicitly.

For `DispatchData`, is there a principled reason there isn’t something like this defined:

struct DispatchDataSegment {
  let bytes: UnsafeBufferPointer<UInt8>
  let byteIndex: Int
}

extension DispatchData {

  /// Returns a sequence that enumerates the contiguous chunks,
  /// e.g. a sequence with elements of type `DispatchDataSegment`.
  ///
  /// Sequence-based eplacement-for `enumerateBytes(_:)`
  var segmentSequence: DispatchDataSegmentSequence { get }

}

…or something analogous (instead of the proposed use dispatch_data_apply?)?

I don’t see any API yet for setting target queues, or getting queue labels. I know the proposal isn’t documenting the APIs in full but it’s hard to evaluate in that absence.

I don’t see basic API on dispatch sources yet for things like setting event handlers, (etc.); again I know the APIs aren’t fully specified here but it’s hard to evaluate something that’s not fully specified.

···

  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Austin Zheng) #20

I also think that this proposal highlights a reason why the stdlib should
have some sort of 'indigenous' binary data capability, given that both
Foundation and libdispatch would theoretically be able to leverage such a
feature.

Austin

···

On Tue, May 10, 2016 at 10:22 PM, Austin Zheng <austinzheng@gmail.com> wrote:

I think this is a great idea and a great proposal. GCD is already a
powerful, elegant tool available to Swift users, and this makes it feel
even more Swift-like.

Feedback/questions:
- Is there a use case for user subclassing of a queue type? If not, should
they be final?
- Is there a reason to use class methods rather than static methods for
the queue types? I was under the impression that static methods would be
preferred unless a good reason exists to dispatch upon metatype.
- Nit: "DispatchWallTime" is spelled "DispatchWalltime" (lowercase 't')
in the code samples.
- Is it allowed/technically possible for non-stdlib code to use
_ObjectiveCBridgable?

Best,
Austin

On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0088: Modernize libdispatch for Swift 3 naming
conventions" begins now and runs through May 17. The proposal is available
here:

https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of Swift.
When writing your review, here are some questions you might want to answer
in your review:

        * What is your evaluation of the proposal?
        * Is the problem being addressed significant enough to warrant a
change to Swift?
        * Does this proposal fit well with the feel and direction of
Swift?
        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution