[swift-evolution] [Accepted with Revision] SE-0088: Modernize libdispatch for Swift 3 naming conventions

[Chris Lattner]

> On May 19, 2016, at 10:02 PM, Dan Appel <dan.appel00 at gmail.com> wrote:
> 
> >Swift 2.2 code should be run through a migrator, which is able to automatically handle changes like this.
> 
> Yes, but that's not really my point. Why do it this "magical" way?

Because it means that there is exactly one API: not a canonical API and a similar-but-different and less efficient wrapper.  The approach taken here generalizes to other (similarly structured) C APIs as well.

As I mentioned before this isn’t about breaking code, so let me flip your question around: Why not do it?  

-Chris


> It's already possible (and actually very easy) to wrap C modules such as libdispatch in a Swifty API (see Venice <https://github.com/VeniceX/Venice>, OpenSSL <https://github.com/Zewo/OpenSSL>, PostreSQL <https://github.com/Zewo/PostgreSQL> as examples). I know that LibDispatch is special to Swift and Apple, but I just don't see a reason to give it such a special treatment.
> 
> Dan
> 
> On Thu, May 19, 2016 at 9:56 PM Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
> 
> > On May 19, 2016, at 9:53 PM, Dan Appel <dan.appel00 at gmail.com <mailto:dan.appel00 at gmail.com>> wrote:
> >
> > Does this mean that all current code using Dispatch is broken?
> 
> Are you asking about Swift 2.2 code?
> 
> Swift 2.2 code is generally completely incompatible with Swift 3 for a lot of other reasons (e.g. major changes to the standard library APIs).  Swift 2.2 code should be run through a migrator, which is able to automatically handle changes like this.
> 
> -Chris
> -- 
> Dan Appel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160519/f5e204bd/attachment.html>