> On Jan 26, 2017, at 9:48 PM, Dave Abrahams via swift-evolution > <swift-evolution@swift.org> wrote: > > > on Thu Jan 26 2017, Matthew Johnson <swift-evolution@swift.org> wrote: > >>> On Jan 26, 2017, at 3:10 PM, Dave Abrahams via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>> on Thu Jan 26 2017, David Hart <swift-evolution@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.
Yes, for sure. I just don’t want to see us end up with baggage in the long run because we made promises when foreseeable changes were still on the horizon. Swift 3 migration has definitely caused some pain. For a small to moderate sized app with a small team it is kind of annoying not really that bad (a couple days tops). For larger apps with larger teams it is pretty disruptive. I’ll be part of the migration effort for a fairly large app in the near future. I’m really interested to see how that migration plays out. I imagine future source breaking changes will be much more modest and we will have a better story around dependencies so I expect the pain will be significantly less. We will also have the experience of the Swift 3 migration which will help in weighing what the real world cost of specific proposed changes might be. > > -- > -Dave > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
