Hi Nevin, I think it is important to separate the issues of concern here, as I think too much is get conflated into one topic. ABI stability doesn’t mean that the language or Standard Library can’t change in the future. It *does* mean we can’t just remove APIs wholesale that clients may depend on today, but I feel we are already in that place with the Standard Library. For the Standard Library, ABI stability brings promises for binary compatibility for future versions of the Standard Library to clients that link against it — but that doesn’t mean that APIs can’t be deprecated and/or phased out in practice and new ones introduced. For example, with Mirror, we may need to keep the existing Mirror APIs in place for existing clients that depend on them, but that doesn’t mean we couldn’t introduce better alternatives to Mirror in the future.
When talking about what ABI stability means, I think it is important to be technically specific about what it means and what it doesn’t mean. For example, the wording you chose here was “still be able to fix the parts that we can already see need fixing” as if ABI stability would prevent you from doing that. It is true that ABI stability means we can’t make certain kinds of changes — that’s what the “stability” of ABI stability means — but for the Standard Library ABI stability more-or-less brings the same kind of mental model for stability that most clients expect out of stable libraries these days: APIs can evolve, new ones can be added, and old ones can be deprecated/phased out, but existing clients that depend on the old interfaces need to continue to work. That model is not incompatible with “fixing” APIs; it just means that “fixing” takes on different forms than just wholesale ripping out old APIs and replacing them with totally different ones. We’re rapidly moving past that point with the evolution of the Standard Library anyway, and I think that’s something worth keeping in mind. I’m totally open to considering “carving out specific exemptions to ABI stability” — I think specific arguments could be made here. But I think those should be technically well considered on a case-by-case basis, and not just fear that ABI stability will lock us into bad APIs permanently. Even outside of the current APIs we feel today might be imperfect, inevitably down the road we’re going to look back at some APIs and say that we wish we did them differently and find ways to phase in changes/improvements if the need is great. Ted > On Jan 9, 2018, at 6:30 PM, Nevin Brackett-Rozinsky via swift-evolution > <swift-evolution@swift.org> wrote: > > I’m just spitballing here, and I’m not an expert on matters of ABI, however > the thought occurs to me that the current all-or-nothing approach might lead > to suboptimal results. > > In particular, some recent discussions on this list have mentioned that > certain parts of the standard library, such as Mirror, really ought to be > redesigned. But their current shape is on track to be baked into the > permanent ABI, even though we know right now that we can do better. > > Has any consideration been given to the possibility of carving out specific > exemptions to ABI stability for Swift 5, and saying something like, “The > entire ABI will be stabilized, except for Mirror (and possibly a small number > of other things)”? > > That way we can nail down almost all of the ABI, while still being able to > fix the parts that we can already see need fixing. Perhaps I am being naive > here, and I’m sure there are major aspects I am unaware of, but from my > layperson’s perspective it seems rather silly to tie ourselves to a legacy > implementation that we want to redesign. > > Nevin > _______________________________________________ > 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
