[swift-evolution] A case for postponing ABI stability

[Freak Show]

I do not see how you can consider standardizing ABI without first standardizing the dynamic features and the desired programmatic interfaces to them.  

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. 



> On Jan 24, 2017, at 11:45, Rahul Malik via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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.
> 
> Below are some thoughts from my perspective as someone involved in the decision to adopt Swift in production at work.
> 
> ABI Stability
> 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.
> 
> API Stability
> 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.
> 
> 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."
> 
> On Tue, Jan 24, 2017 at 3:16 AM, Georgios Moschovitis via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> > 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 ;-)
> 
> +1
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170124/bfa34698/attachment.html>