> On Jan 9, 2018, at 6:50 PM, Jon Hull via swift-evolution > <swift-evolution@swift.org> wrote: > >> 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. >
> 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 gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
