<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I do not see how you can consider standardizing ABI without first standardizing the dynamic features and the desired programmatic interfaces to them. <div class=""><br class=""></div><div class="">We know that dynamic features need to come. They will impact everything. My personal ideal is a language that smoothly transitions from fully dynamic to fully static without a lot of fuss. </div><div class=""><br class=""><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 24, 2017, at 11:45, Rahul Malik via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><span style="font-size:12.8px" class="">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 class=""><span style="font-size:12.8px" class=""><br class=""></span></div><div class=""><span style="font-size:12.8px" class="">Below are some thoughts from my perspective as someone involved in the decision to adopt Swift in production at work.<br class=""></span><div class=""><span style="font-size:12.8px" class=""><br class=""></span></div><div class=""><span style="font-size:12.8px" class=""><b class="">ABI Stability</b></span></div><div class=""><span style="font-size:12.8px" class="">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 class=""></span><div class=""><span style="font-size:12.8px" class=""><br class=""></span></div><div class=""><span style="font-size:12.8px" class=""><b class="">API Stability</b><br class=""></span><div class="">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 class=""><br class=""></div><div class="">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 class=""><div class="gmail_quote">On Tue, Jan 24, 2017 at 3:16 AM, Georgios Moschovitis via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><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 class="">
<br class="">
</span>+1<br class="">
<div class="HOEnZb"><div class="h5"><br class="">
______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class="">
</div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>