<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hey Jacob,</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I agree with you that there are some unanswered questions and areas we would need some more polish on, but libdispatch was a bit unwieldy in Objective-C already and when used as is in Swift code it looks to be even less user friendly and not because it has to, but because of a lack of proper improvements such as the one described here. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I strongly hope we can get this in time for Swift 3... (not given up on cleaner dispatching rules for protocols and protocol extensions, but that's another story :)).</div><div id="AppleMailSignature"><br>Sent from my iPhone</div><div><br>On 11 May 2016, at 07:52, Jacob Bandes-Storch via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br> * What is your evaluation of the proposal?<br><div><br></div><div>I'm generally in favor of a modernized API overlay like this (and I've written <a href="https://gist.github.com/jtbandes/a5ce62019585dd4f998e">something like it</a> myself, albeit much simpler), but I'm hoping this proposal can go through another round or two of discussion/bikeshedding/revision before approval.<div><br></div><div>(Small note: I'm really happy about the strong-typed-ness of the Source subclasses, e.g. how mergeData is only available for Add/Or.)<br><div><br></div><div>In no particular order, here are some things on which I'm unclear, or not-so-+1:</div><div><br></div><div>- synchronously()'s block parameter should be @noescape. Perhaps more arguably, it should have a generic return type and rethrows, like <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0061-autoreleasepool-signature.md">autoreleasepool now does</a>.</div><div><br></div><div>- The names asynchronously(execute:) and synchronously(execute:) don't seem to fit with any API guidelines I'm aware of. Did you consider including the verb in the method name? (And I'm guessing that "func synchronously(work:...)" is meant to be "func synchronously(execute work:...)"?) As another bikeshed-item, I'd vote for "Data.init(withoutCopying:...)" rather than "(bytesNoCopy:...)", and perhaps whenDone() instead of notify().</div><div><br></div><div>- Are DispatchWorkItemFlags meant to overlay dispatch_block_flags? It would be nice to explicitly list these in the proposal.</div><div><br></div><div>- Are functions like dispatch_barrier_sync totally gone in favor of passing a .barrier flag? It would be nice to explicitly state this in the proposal.</div><div><br></div><div>- I echo Austin's concerns about subclassability. I think it would be dangerously misleading if the classes were subclassable from user code, even if it didn't work properly.</div><div><br></div><div>- What of the APIs provided on Semaphore and Group objects? I'd like to see these before I vote for the proposal.</div><div><br></div><div>- What will dispatch_set_target_queue's replacement look like look like?</div><div><br></div><div>- What about dispatch_once?</div><div><br></div><div>- Why use class funcs for the Source initializers, rather than an init on each individual subclass?</div><div><br></div><div>- Since DispatchSpecificKey is an object now, is there any concern with the object being allocated at the same address as an old, since-deallocated, object? (This might cause user confusion if both were used as "different" keys.)<br><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"> * Is the problem being addressed significant enough to warrant a change to Swift?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Yes.</div><div class="gmail_extra"><br> * Does this proposal fit well with the feel and direction of Swift?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Getting there.</div><div class="gmail_extra"><br> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Medium-quick reading of this proposal. I've thought about this issue a good deal in the past, though.</div><div><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>Jacob<br></div></div></div></div>
<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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);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>
<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>
</blockquote></div><br></div></div></div></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>