<div dir="ltr"><span style="font-size:12.8px">I agree that we shouldn't rush decisions but I feel like the emphasis of ABI stability has been a factor in discussing a number of proposals for Swift 4 and has been a core goal of this next major release. Seems strange to deemphasize it and its importance at this time.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Below are some thoughts from my perspective as someone involved in the decision to adopt Swift in production at work.<br></span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><b>ABI Stability</b></span></div><div><span style="font-size:12.8px">The reality is that stability in the ABI is important for a number of developers and companies considering adopting or that have already adopted Swift. Shipping the runtime increases the binary size of every app that ships with it and becomes a barrier in user acquisition due to the increased app size. If I'm not mistaken this issue multiplies as you add extensions to your application since they all bundle the runtime separately. Due to these issues, ABI Stability is one of the leading reasons we have not adopted Swift in our flagship app.<br></span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><b>API Stability</b><br></span><div>This I would consider just as important as the ABI stability. Changing APIs provides a lot of churn on developers that manage large codebases and I've often heard of issues using the Swift migrator at scale which doesn't help. I'd like to see a less drastic approach like Jonathan is suggesting where we have clear indication of APIs that might change or at least allowing one minor release where an API will warn if it's used but is still available to allow developers time to migrate.</div></div></div></div><div><br></div><div>Right now I think it's important to keep ABI stability as a core tenant of any proposal and acknowledge that we need to just flag how proposals will affect ABI stability. This seems inline with our stance on the development of a Rust-inspired `Memory Ownership Model`: "While a full memory ownership model is likely too large for Swift 4 stage 1, we need a comprehensive design to understand how it will change the ABI."</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 24, 2017 at 3:16 AM, Georgios Moschovitis via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> I'm not really sure if the String-changes affect the ABI, but none the less, I strongly agree with your opinion that things shouldn't be done in a hurry, and I hope that Swift keeps the courage to break things for the better (sporadically ;-)<br>
<br>
</span>+1<br>
<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div>