Incremental ABI stability

Evolution Discussion
1

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.

Nevin

2

+1000

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.

Thanks,
Jon

···

Sent from my iPhone

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.

Nevin
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

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.

···

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.

--
Greg Parker gparker@apple.com <mailto:gparker@apple.com> Runtime Wrangler

4

Hi Nevin,

I think it is important to separate the issues of concern here, as I think too much is get conflated into one topic. ABI stability doesn’t mean that the language or Standard Library can’t change in the future. It *does* mean we can’t just remove APIs wholesale that clients may depend on today, but I feel we are already in that place with the Standard Library. For the Standard Library, ABI stability brings promises for binary compatibility for future versions of the Standard Library to clients that link against it — but that doesn’t mean that APIs can’t be deprecated and/or phased out in practice and new ones introduced. For example, with Mirror, we may need to keep the existing Mirror APIs in place for existing clients that depend on them, but that doesn’t mean we couldn’t introduce better alternatives to Mirror in the future.

When talking about what ABI stability means, I think it is important to be technically specific about what it means and what it doesn’t mean. For example, the wording you chose here was “still be able to fix the parts that we can already see need fixing” as if ABI stability would prevent you from doing that. It is true that ABI stability means we can’t make certain kinds of changes — that’s what the “stability” of ABI stability means — but for the Standard Library ABI stability more-or-less brings the same kind of mental model for stability that most clients expect out of stable libraries these days: APIs can evolve, new ones can be added, and old ones can be deprecated/phased out, but existing clients that depend on the old interfaces need to continue to work. That model is not incompatible with “fixing” APIs; it just means that “fixing” takes on different forms than just wholesale ripping out old APIs and replacing them with totally different ones. We’re rapidly moving past that point with the evolution of the Standard Library anyway, and I think that’s something worth keeping in mind.

I’m totally open to considering “carving out specific exemptions to ABI stability” — I think specific arguments could be made here. But I think those should be technically well considered on a case-by-case basis, and not just fear that ABI stability will lock us into bad APIs permanently. Even outside of the current APIs we feel today might be imperfect, inevitably down the road we’re going to look back at some APIs and say that we wish we did them differently and find ways to phase in changes/improvements if the need is great.

Ted

···

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.

Nevin
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

5

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 gparker@apple.com <mailto:gparker@apple.com> Runtime Wrangler

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

6

For reference, Chris’s idea can be found here
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20180108/042668.html&gt;
.

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 gparker@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 gparker@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