<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 9, 2018, at 6:50 PM, Jon Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Jan 9, 2018, at 6:30 PM, Nevin Brackett-Rozinsky via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">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)”?<br class=""><br class="">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.</blockquote></div></div></blockquote><blockquote type="cite" class=""><br class=""></blockquote></div><div><blockquote type="cite" class="">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.<br class=""></blockquote></div><br class=""><div class="">This model is unlikely to work well. </div><div class=""><br class=""></div><div class="">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:</div><div class="">1. Apps use the feature. In some future OS version we break them and they crash. Users are unhappy.</div><div class="">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.</div><div class=""><br class=""></div><div class="">I think we're more likely to simply delete a feature with no replacement than to do the above.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">-- </div><div class="">Greg Parker <a href="mailto:gparker@apple.com" class="">gparker@apple.com</a> Runtime Wrangler</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>