Sent from my iPhone
> On 27 Jan 2017, at 07:04, Goffredo Marocchi <pana...@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@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. >> >> -- >> -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
