[swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

[Goffredo Marocchi]

Hey Jacob,

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. 

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 :)).

Sent from my iPhone

> On 11 May 2016, at 07:52, Jacob Bandes-Storch via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>         * What is your evaluation of the proposal?
> 
> I'm generally in favor of a modernized API overlay like this (and I've written something like it myself, albeit much simpler), but I'm hoping this proposal can go through another round or two of discussion/bikeshedding/revision before approval.
> 
> (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.)
> 
> In no particular order, here are some things on which I'm unclear, or not-so-+1:
> 
> - synchronously()'s block parameter should be @noescape. Perhaps more arguably, it should have a generic return type and rethrows, like autoreleasepool now does.
> 
> - 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().
> 
> - Are DispatchWorkItemFlags meant to overlay dispatch_block_flags? It would be nice to explicitly list these in the proposal.
> 
> - 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.
> 
> - 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.
> 
> - What of the APIs provided on Semaphore and Group objects? I'd like to see these before I vote for the proposal.
> 
> - What will dispatch_set_target_queue's replacement look like look like?
> 
> - What about dispatch_once?
> 
> - Why use class funcs for the Source initializers, rather than an init on each individual subclass?
> 
> - 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.)
> 
> 
>         * Is the problem being addressed significant enough to warrant a change to Swift?
> 
> Yes.
> 
>         * Does this proposal fit well with the feel and direction of Swift?
> 
> Getting there.
> 
>         * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> 
> Medium-quick reading of this proposal. I've thought about this issue a good deal in the past, though.
> 
> Jacob
> 
>> On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution <swift-evolution at 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:
>> 
>> 
>> 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160511/2a5c6d95/attachment.html>