[swift-evolution] A case for postponing ABI stability

[Matthew Johnson]

> On Jan 26, 2017, at 8:22 PM, Michael Ilseman <milseman at apple.com> wrote:
> 
> 
>> On Jan 26, 2017, at 5:48 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> 
>> On Jan 26, 2017, at 7:29 PM, Ted Kremenek <kremenek at apple.com <mailto:kremenek at apple.com>> wrote:
>> 
>>> 
>>>> On Jan 26, 2017, at 12:19 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> Locking down ABI when all foreseeable desirable changes are additive is one thing.  But doing so before we get there feels premature.
>>> 
>>> 
>>> I fully agree that locking down the ABI prematurely would be detrimental to the long-term future of the language.
>>> 
>>> Part of the point of the ABI manifesto is to scope out what are the desirable or critical changes needed before ABI gets locked down.  From that we can have concrete discussions on what’s left to be done, how much work it will take to get there, etc.
>> 
>> That makes perfect sense.  
>> 
>> One thing that isn't clear in the manifesto that I think a lot of us are wondering about is what language features are important to the long-term desired design of the standard library that aren't in place yet?  There has been some informal discussion of this on the list but nothing more and it hasn't been clear whether those features will be ready by the time ABI stability is locked down.   Maybe the manifesto is a good place to start documenting more formally the language features needed to realize the desired design of the standard library APIs that will be present when the ABI is declared stable.
> 
> There’s a bit of a chicken-and-the-egg problem here, where the stdlib will discover better APIs after playing with new language features. This is one of the reasons for the intense focus in Swift 4 phase 1.

Yes of course.  But I imagine we could come up with a reasonable list of language features that we *think* would have an impact on the library APIs that exist today.

> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/20170127/421c99a5/attachment.html>