[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 (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 have to be rewritten. That is not ok.

Another issues is the proposal to 'automagically' translate the C api into
Swift. 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 of the proposed 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 (which is what the community is currently doing).

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