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. -- -Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution