[swift-evolution] Incremental ABI stability

[Nevin Brackett-Rozinsky]

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 at 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 at swift.org> wrote:
>
>
> On Jan 9, 2018, at 6:50 PM, Jon Hull via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Jan 9, 2018, at 6:30 PM, Nevin Brackett-Rozinsky via swift-evolution <
> swift-evolution at 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     gparker at apple.com     Runtime Wrangler
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at 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 at 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 at swift.org> wrote:
>
>
> On Jan 9, 2018, at 6:50 PM, Jon Hull via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Jan 9, 2018, at 6:30 PM, Nevin Brackett-Rozinsky via swift-evolution <
> swift-evolution at 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     gparker at apple.com     Runtime Wrangler
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180110/163dc7dd/attachment.html>