[swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions
Patrick Smith
pgwsmith at gmail.com
Wed May 11 00:41:55 CDT 2016
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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
More information about the swift-evolution
mailing list