Right, I understand that part. ABI stability means that we can run past binaries without recompiling.
What I want to know is what sorts of things affect this stability and which things don’t. I guess I want heuristics for knowing whether an idea will affect the ABI, and thus needs to be talked about now. I don’t want to distract from the process by proposing features which can be tackled later, but at the same time I REALLY don’t want to wait until phase 2 and then be told the feature can never be added because it would break the ABI (and I should have proposed it during phase 1). Thanks, Jon > On Aug 11, 2016, at 4:24 AM, Anton Zhilin <antonyzhi...@gmail.com> wrote: > > 2016-08-11 11:52 GMT+03:00 Jonathan Hull via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>: > Could someone explain in simple terms what the ABI is and what sorts of > things might affect it? > > I had thought it was the layout in memory of structs/classes/etc… and how the > program knows where to go to find a particular field. This seems to be > incorrect though, as I have seen many features that I would assume have some > affect on this layout ruled “out of scope for phase 1”. For example, I would > think that many generics features would have an impact on the ABI, or the > idea of COW (via secret boxing) for structs, or even union types. > > At the very least, I would think that mix-ins would have a fairly significant > effect. > > ABI stability means that changes will have to be backwards compatible after a > certain stage. If we can add mixins feature without modifying old code (and > its SIL and IR and whatever), then we are fine.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
