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

[Dan Appel]

> 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
> 
> 
> 


Ok, I have mixed feeling about this proposal.

First, this is a huge breaking change, and it doesn’t really have to be one. The current SPM convention is to prefix C libraries with Lib. Following this convention, Dispatch (which is the C version) would be renamed to LibDispatch, and this new wrapper library would be called just Dispatch. With this setup, the old C api would still be there (under the module LibDispatch), which makes migration much easier. In the proposal, this issue is not addressed at all and it even says that all code using libdispatch would be affected. As it stands, that is not ok.

On a different issue in this proposal: I think that translating the C api into Swift ‘automagically’ is the wrong approach. There are many libraries right now that wrap the current libdispatch functions and provide a similar api, and I don’t think there’s any reason why this shouldn’t be done the same way. I would also argue that doing this links the Swift language to libdispatch in a way that isn’t necessary. For example, there is a library called Venice <https://github.com/VeniceX/Venice> which provides CSP (go-style concurrency) for Swift by wrapping a fork of the C library libmill, and it doesn’t do any magic importing of any sort. I don’t see a reason why libdispatch shouldn’t take the same approach.

Overall, I think the idea is good but some of the details are really lacking. As it stands, I would vote to reject this proposal and request revision, or reject it outright and suggest to use third-party wrappers around libdispatch (like the community is already doing).

Dan Appel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160512/c346deef/attachment.html>