Excellent, thanks for answering my questions! If the classes should/can not be subclassed, they should probably be marked as 'final' in order to make this clear to consumers, regardless of performance or correctness implications.
Austin On Tue, May 10, 2016 at 11:12 PM, Matt Wright <m...@apple.com> wrote: > > > On May 10, 2016, at 10:22 PM, Austin Zheng via swift-evolution < > swift-evolution@swift.org> 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 < > 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 > > > > _______________________________________________ > > swift-evolution mailing list > > swift-evolution@swift.org > > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
