[swift-evolution] A case for postponing ABI stability

[Dave Abrahams]

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