For reference, Chris’s idea can be found here <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20180108/042668.html> .
Nevin On Wed, Jan 10, 2018 at 5:22 PM, Hooman Mehr via swift-evolution < swift-evolution@swift.org> wrote: > 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> 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 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 > > On Wed, Jan 10, 2018 at 5:22 PM, Hooman Mehr via swift-evolution < swift-evolution@swift.org> wrote: > 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> 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 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 > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
