> On Jan 26, 2017, at 8:22 PM, Michael Ilseman <milse...@apple.com> wrote: > > >> On Jan 26, 2017, at 5:48 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >> >> Sent from my iPad >> >> On Jan 26, 2017, at 7:29 PM, Ted Kremenek <kreme...@apple.com >> <mailto:kreme...@apple.com>> wrote: >> >>> >>>> On Jan 26, 2017, at 12:19 PM, Matthew Johnson via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> Locking down ABI when all foreseeable desirable changes are additive is >>>> one thing. But doing so before we get there feels premature. >>> >>> >>> I fully agree that locking down the ABI prematurely would be detrimental to >>> the long-term future of the language. >>> >>> Part of the point of the ABI manifesto is to scope out what are the >>> desirable or critical changes needed before ABI gets locked down. From >>> that we can have concrete discussions on what’s left to be done, how much >>> work it will take to get there, etc. >> >> That makes perfect sense. >> >> One thing that isn't clear in the manifesto that I think a lot of us are >> wondering about is what language features are important to the long-term >> desired design of the standard library that aren't in place yet? There has >> been some informal discussion of this on the list but nothing more and it >> hasn't been clear whether those features will be ready by the time ABI >> stability is locked down. Maybe the manifesto is a good place to start >> documenting more formally the language features needed to realize the >> desired design of the standard library APIs that will be present when the >> ABI is declared stable. > > There’s a bit of a chicken-and-the-egg problem here, where the stdlib will > discover better APIs after playing with new language features. This is one of > the reasons for the intense focus in Swift 4 phase 1.
Yes of course. But I imagine we could come up with a reasonable list of language features that we *think* would have an impact on the library APIs that exist today. > >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto: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
