[swift-evolution] Swift 4, stage 2 starts now

Ted Kremenek kremenek at apple.com
Fri Feb 17 11:30:40 CST 2017

> On Feb 16, 2017, at 10:17 PM, Chris Lattner <clattner at nondot.org> wrote:
> On Feb 16, 2017, at 4:18 PM, Ted Kremenek via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> Deferring ABI Stability from Swift 4
>> Given the importance of getting the core ABI and the related fundamentals correct, we are going to defer the declaration of ABI stability out of Swift 4 while still focusing the majority of effort to get to the point where the ABI can be declared stable.
> Given where we are in the yearly schedule, I think that this is a pragmatic decision.  ABI stability is far more important to Apple than it is to most developers, so I’m happy to see that you’re prioritizing the needs of the community (improved compile time, compiler stability, etc), particularly given the importance of doing the right thing for the long term success of Swift.
> Beyond that, I agree that it is prudent to continue work on the many ABI stability tasks despite it not being a goal for Swift 4.  Given the significance of declaring ABI stability, it would be great to get these tasks really nailed down early in the Swift 5 schedule so you have time to bake it out.

Absolutely — giving time for these changes to bake to make sure we did not miss anything is essential part of keeping the focus in Swift 4 on core ABI stability tasks (and other language fundamentals that impact ABI and source stability).  That thinking went into the scoping of stage 2.

> Do you have any idea what the typical download size impact of the Swift 4 libraries will be on the ARM64 slice of a typical iOS app?  I know that many of the ABI-related optimizations also contribute to a significant code size improvement, but don’t know how folks expect that to net out.  Do you think that it is plausible to get the overlays coalesced with the stdlib into a single dylib, improving app launch times?

This is an interesting idea, but off-topic for swift-evolution.  A better place to discuss this is swift-dev.

That said, there are tradeoffs here: creating a single dylib slightly complicates the long-term goal of sinking the overlay APIs back into the OS, and the number of overlays is not guaranteed to remain fixed so the tradeoffs of creating a single dylib versus multiple are nuanced.  The focus has been on the ABI-related optimizations, such as reducing the size of mangled symbols, which are tasks that absolutely need to be done before ABI stability.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170217/73fcf346/attachment.html>

More information about the swift-evolution mailing list