<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="" applecontenteditable="true"><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 16, 2017, at 10:17 PM, Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Feb 16, 2017, at 4:18 PM, Ted Kremenek via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="" applecontenteditable="true"><h3 id="toc_0" style="-webkit-print-color-adjust: exact; margin: 20px 0px 10px; padding: 0px; -webkit-font-smoothing: antialiased; cursor: text; position: relative; font-size: 18px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">Deferring ABI Stability from Swift 4</h3><p style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; font-size: 14px; background-color: rgb(255, 255, 255);" class="">Given the importance of getting the core ABI and the related fundamentals correct, we are going to <strong style="-webkit-print-color-adjust: exact;" class="">defer the declaration of ABI stability out of Swift 4</strong> while still focusing the <b class="">majority</b> of effort to get to the point where the ABI can be declared stable.</p></div></div></blockquote>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.</div><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">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?</div></div></div></blockquote><br class=""></div><div>This is an interesting idea, but off-topic for swift-evolution. A better place to discuss this is swift-dev.</div><div><br class=""></div><div>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.</div></body></html>