I think the best solution is Chris Lattner’s suggestion (responding to DictionaryLiteral) to split the shaky stuff into an overlay for Swift standard library to maintain compatibility.
> On Jan 10, 2018, at 2:12 PM, Greg Parker via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Jan 9, 2018, at 6:50 PM, Jon Hull via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Jan 9, 2018, at 6:30 PM, Nevin Brackett-Rozinsky via swift-evolution >>> <swift-evolution@swift.org <mailto: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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
