[swift-evolution] [Accepted with Revision] SE-0088: Modernize libdispatch for Swift 3 naming conventions
dan.appel00 at gmail.com
Fri May 20 00:17:33 CDT 2016
>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
I don't see any mention of this in the proposal. Is this related to the
other C api translation proposal?
>Why not do it?
Well, I want "equal opportunity" for all libraries. I am a huge fan of the
structured concurrency scheme that Venice
<https://github.com/VeniceX/Venice> provides by wrapping libmill, and I
don't want it (or any other C libraries) to lag behind LibDispatch simply
because it is not Apple's own. If the changes in this proposal do affect
all c libraries, then obviously I am all for it. But the way I see it, and
please correct me if I am mistaken, giving LibDispatch special treatment
adds an extra crutch to other third party libraries which would otherwise
be on a level playing field.
On Thu, May 19, 2016 at 10:05 PM Chris Lattner <clattner at apple.com> wrote:
> 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?
> 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.
> On Thu, May 19, 2016 at 9:56 PM Chris Lattner <clattner at apple.com> wrote:
>> > On May 19, 2016, at 9:53 PM, Dan Appel <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.
> Dan Appel
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution