> On May 10, 2016, at 10:22 PM, Austin Zheng via swift-evolution > <[email protected]> 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?
Currently it’s not possible to subclass these classes in Objective C either, the metaclass symbols for the libdispatch Objective-C classes are not exported. This same restriction applies to those classes when interacting with them in swift, even though the classes themselves are not marked `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. This detail passed me by, I will investigate. > - Nit: "DispatchWallTime" is spelled "DispatchWalltime" (lowercase 't') in > the code samples. I apologise, along with the one or two other spelling/naming issues others have pointed out. One or two of these names changed recently and I clearly didn’t catch all of them. > - Is it allowed/technically possible for non-stdlib code to use > _ObjectiveCBridgable? Similar to the Foundation mutability proposal, this will end up being an internal implementation detail of DispatchData’s struct bridging. Regards, M > > Best, > Austin > > > On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution > <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
