<div dir="ltr">For reference, Chris’s idea can be found <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20180108/042668.html">here</a>.<div><br></div><div>Nevin</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 10, 2018 at 5:22 PM, Hooman Mehr via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">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.<br><div><br><blockquote type="cite"><div><div class="h5"><div>On Jan 10, 2018, at 2:12 PM, Greg Parker via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-1061146825220169590Apple-interchange-newline"></div></div><div><div><div class="h5"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><blockquote type="cite"><div>On Jan 9, 2018, at 6:50 PM, Jon Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><div><div><br><blockquote type="cite">On Jan 9, 2018, at 6:30 PM, Nevin Brackett-Rozinsky via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br>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><br>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><br>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><br>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"><br></blockquote></div><div><blockquote type="cite">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></blockquote></div><br><div>This model is unlikely to work well. </div><div><br></div><div>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>1. Apps use the feature. In some future OS version we break them and they crash. Users are unhappy.</div><div>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><br></div><div>I think we're more likely to simply delete a feature with no replacement than to do the above.</div><div><br></div><div><br></div><div>-- </div><div>Greg Parker <a href="mailto:gparker@apple.com" target="_blank">gparker@apple.com</a> Runtime Wrangler</div><div><br></div><div><br></div></div></div></div><span class="">______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></span></div></blockquote></div><br></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 10, 2018 at 5:22 PM, Hooman Mehr via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">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.<br><div><br><blockquote type="cite"><div><div class="h5"><div>On Jan 10, 2018, at 2:12 PM, Greg Parker via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-1061146825220169590Apple-interchange-newline"></div></div><div><div><div class="h5"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><blockquote type="cite"><div>On Jan 9, 2018, at 6:50 PM, Jon Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><div><div><br><blockquote type="cite">On Jan 9, 2018, at 6:30 PM, Nevin Brackett-Rozinsky via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br>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><br>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><br>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><br>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"><br></blockquote></div><div><blockquote type="cite">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></blockquote></div><br><div>This model is unlikely to work well. </div><div><br></div><div>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>1. Apps use the feature. In some future OS version we break them and they crash. Users are unhappy.</div><div>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><br></div><div>I think we're more likely to simply delete a feature with no replacement than to do the above.</div><div><br></div><div><br></div><div>-- </div><div>Greg Parker <a href="mailto:gparker@apple.com" target="_blank">gparker@apple.com</a> Runtime Wrangler</div><div><br></div><div><br></div></div></div></div><span class="">______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></span></div></blockquote></div><br></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>