<div dir="ltr">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?<div><br><div>One more nit: "DispatchSourceMachRecv" in the table, but "DispatchSourceMachReceive" in the code sample.</div></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 11, 2016 at 12:24 AM, Austin Zheng via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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 feature.<div><br></div><div>Austin</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 10, 2016 at 10:22 PM, Austin Zheng <span dir="ltr"><<a href="mailto:austinzheng@gmail.com" target="_blank">austinzheng@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>Feedback/questions:</div><div>- Is there a use case for user subclassing of a queue type? If not, should they be final?</div><div>- 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.</div><div>- Nit: "<span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.6px;line-height:21.76px;background-color:rgba(0,0,0,0.0392157)">DispatchWallTime</span>" is spelled "<span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.6px;line-height:1.45;background-color:rgb(247,247,247)">DispatchWalltime</span>" (lowercase 't') in the code samples.</div><div>- Is it allowed/technically possible for non-stdlib code to use _ObjectiveCBridgable?</div><div><br></div><div>Best,</div><div>Austin</div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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" target="_blank">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>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><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></blockquote></div><br></div></div>