[swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions
xiaodi.wu at gmail.com
Wed May 11 00:31:58 CDT 2016
Did not see this proposal coming down the pipeline, but a more Swift-like
GCD will be fantastic. In terms of painting the bike shed, I'm not quite
sure about having adverbs "synchronously" and "asynchronously" as method
names. Conveniently, "sync" and "async" avoid the issue entirely, and they
are pretty widespread and acceptable as terms of art, no?
One more nit: "DispatchSourceMachRecv" in the table, but
"DispatchSourceMachReceive" in the code sample.
On Wed, May 11, 2016 at 12:24 AM, Austin Zheng via swift-evolution <
swift-evolution at swift.org> wrote:
> 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
> On Tue, May 10, 2016 at 10:22 PM, Austin Zheng <austinzheng at gmail.com>
>> 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.
>> - 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
>> On Tue, May 10, 2016 at 9: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
>>> Reviews are an important part of the Swift evolution process. All
>>> reviews should be sent to the swift-evolution mailing list at
>>> 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
>>> * 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
>>> Thank you,
>>> -Chris Lattner
>>> Review Manager
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution