<div dir="ltr">Excellent, thanks for answering my questions!<div><br></div><div>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.</div><div><br></div><div>Austin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 10, 2016 at 11:12 PM, Matt Wright <span dir="ltr"><<a href="mailto:mww@apple.com" target="_blank">mww@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On May 10, 2016, at 10:22 PM, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> 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.<br>
><br>
> Feedback/questions:<br>
> - Is there a use case for user subclassing of a queue type? If not, should they be final?<br>
<br>
</span>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`.<br>
<span class=""><br>
> - 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.<br>
<br>
</span>This detail passed me by, I will investigate.<br>
<span class=""><br>
> - Nit: "DispatchWallTime" is spelled "DispatchWalltime" (lowercase 't') in the code samples.<br>
<br>
</span>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.<br>
<span class=""><br>
> - Is it allowed/technically possible for non-stdlib code to use _ObjectiveCBridgable?<br>
<br>
</span>Similar to the Foundation mutability proposal, this will end up being an internal implementation detail of DispatchData’s struct bridging.<br>
<br>
Regards,<br>
M<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Best,<br>
> Austin<br>
><br>
><br>
> On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
> Hello Swift community,<br>
><br>
> The review of "SE-0088: Modernize libdispatch for Swift 3 naming conventions" begins now and runs through May 17. The proposal is available here:<br>
><br>
> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md</a><br>
><br>
> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at<br>
><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
> or, if you would like to keep your feedback private, directly to the review manager.<br>
><br>
> What goes into a review?<br>
><br>
> 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:<br>
><br>
> * What is your evaluation of the proposal?<br>
> * Is the problem being addressed significant enough to warrant a change to Swift?<br>
> * Does this proposal fit well with the feel and direction of Swift?<br>
> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br>
> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br>
><br>
> More information about the Swift evolution process is available at<br>
><br>
> <a href="https://github.com/apple/swift-evolution/blob/master/process.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/process.md</a><br>
><br>
> Thank you,<br>
><br>
> -Chris Lattner<br>
> Review Manager<br>
><br>
><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
</div></div></blockquote></div><br></div>