[swift-evolution] A case for postponing ABI stability

Goffredo Marocchi panajev at gmail.com
Fri Jan 27 01:43:45 CST 2017

Sent from my iPhone

> On 27 Jan 2017, at 07:04, Goffredo Marocchi <panajev at gmail.com> wrote:
> In a way some people moved to a new language with few years of life under its belt and should kind of expect the language not offering the stability and maturity something tested and developed over many years like Objective-C provides.
> As mean as that may sound (not trying to be), are the needs of the language and medium term users listened to because of people moving critical production code before it was time?
> Sent from my iPhone
>> On 27 Jan 2017, at 03:48, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> on Thu Jan 26 2017, Matthew Johnson <swift-evolution at swift.org> wrote:
>>>> On Jan 26, 2017, at 3:10 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>>> on Thu Jan 26 2017, David Hart <swift-evolution at swift.org> wrote:
>>>>> Thanks Michael for the manifesto. It definitely made quite a few things clearer for me.
>>>>> Concerning the topic of when ABI stability should happen, I still have
>>>>> a strong feelings that Swift 4 might not be the best time for
>>>>> it. Concerning Data Layout, Type Metadata, Mangling, the Calling
>>>>> Convention and the Runtime, I don’t know enough about them to
>>>>> comment. I’m really centring my discussion on the Standard Library.
>>>>> If we look back at the evolution of the Standard Library for Swift 3,
>>>>> they were many changes. And I’m personally very happy with the
>>>>> thoughtful design that went into those. But they are still a few
>>>>> gotchas, which is to be expected when so many changes are made at
>>>>> once. But we only discover them once the thousands of Swift developers
>>>>> start using those APIs.
>>>>> I just worry that all the big changes that will come for Swift 4 won’t
>>>>> have time to mature. Furthermore, it seems like several extra compiler
>>>>> features which won’t happen in Swift 4 are really necessary to
>>>>> simplify the Standard Library surface area. I’m specifically thinking
>>>>> of type constraints on Existentials which would allow us to get rid of
>>>>> all the Any* structs and replace them with typedefs. But I’m sure
>>>>> there are more examples like those which are just waiting for the
>>>>> generics to become powerful enough to express APIs more elegantly.
>>>>> Perhaps someone from the Standard Library team can chime in to give us
>>>>> their opinion on this topic.
>>>> I have had exactly the same worry for quite some time.  We're still
>>>> waiting for many basic components of the generics system, and, if our
>>>> experience with protocol extensions is any guide, before we have those
>>>> features in hand, it will be impossible to anticipate the design changes
>>>> we'd want to make to the standard library... and that cuts against the
>>>> grain of *source* (to say nothing of ABI) stability.
>>>> So far I've been unable to form a mental model for what source and/or
>>>> ABI stability actually means for our ability to make changes to the
>>>> standard library in the future.  It's possible that we discover a
>>>> workable path forward, but it's equally possible that we find ourselves
>>>> painted into a corner.
>>> I hope we can all agree that the last thing we want to do is get
>>> painted into a corner.  IMO we should be very sure that won’t happen
>>> before making a firm commitment to lock down ABI stability.
>> Unfortunately, even source stability (which is generally a weaker
>> constraint than ABI stability) can have the corner-painting effect, and
>> you really have to weigh that downside off against the cost of breaking
>> people's code when they upgrade their Swift version.  IIUC that has been
>> a major pain point for many people.
>> -- 
>> -Dave
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution

More information about the swift-evolution mailing list