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 

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.


> 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

Reply via email to