On Feb 16, 2017, at 4:18 PM, Ted Kremenek via swift-evolution <[email protected]> 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. 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? -Chris
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
