[swift-evolution] Incremental ABI stability

[Greg Parker]

> On Jan 9, 2018, at 6:50 PM, Jon Hull via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Jan 9, 2018, at 6:30 PM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at 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.
> 

> I would like to be even more conservative, only locking down the things we know we have received actual human attention of some sort. The all-or-nothing approach is actively harmful in my mind.

This model is unlikely to work well. 

Any feature that lacks stable ABI is equivalent to saying "if you use this feature in your app then your app will crash or worse on some future OS version". That in turn leads to two likely outcomes:
1. Apps use the feature. In some future OS version we break them and they crash. Users are unhappy.
2. Apps use the feature. In some future OS version we decide that we can't afford to break them. The "unstable" ABI becomes locked down anyway.

I think we're more likely to simply delete a feature with no replacement than to do the above.


-- 
Greg Parker     gparker at apple.com <mailto:gparker at apple.com>     Runtime Wrangler


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180110/3744baf5/attachment.html>