Ah, I see. I understood on a basic level that additive features were safe, but I didn't/don't have the knowledge to judge when adding actually means changing (e.g. idk, 'adding abstract classes' or 'adding optional protocol methods' implying 'changing/breaking inheritance/dispatch' or something..).
Anyway, I didn't know that about C++ – now *that's *a reassuring benchmark. Thanks! ;) On Fri, Aug 4, 2017 at 8:46 PM, Chris Lattner <[email protected]> wrote: > > > On Aug 4, 2017, at 12:03 PM, Mathew Huusko V <[email protected]> wrote: > > > > Thanks for the swift response, it's an honour; I agree wholeheartedly > with your logic and sentiment. Sorry if I was unclear, but my > concern/curiosity is not for the speed of Swift's development, but in fact > for its long term evolution and longevity. At risk of repeating > myself/boring everyone, that concern manifests over two intermingling > phenomena: > > 1) in the evolution email/proposal archive, a well intentioned (towards > -complexity and +quality) but sometimes blasé air around potential > uses/requirements of the language (~"Swift won't support that because > people probably wouldn't use/need it"). > > 2) the reality of the clock, or what I think/thought the reality was. > Obviously I don't want Swift to evolve too fast, and don't think having any > particular feature right now is worth risking that, but won't the ABI be > stabilised eventually (Swift 5?) and then it will actually be too late for > some features? > > No. ABI stability is less of a bound of new things than it is a bound on > the ability to change existing things. > > To take one random example, C++ has been ABI stable on the Mac since > effectively 10.0 (or whatever release first shipped GCC 3). That hasn’t > impeded the ability to add tons of new stuff to C++. :-) > > -Chris > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
