Re: [swift-evolution] Incremental ABI stability

[Ted Kremenek via swift-evolution]

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

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

Re: [swift-evolution] Incremental ABI stability

[Nevin Brackett-Rozinsky via swift-evolution]

For reference, Chris’s idea can be found here

.

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 

Re: [swift-evolution] Incremental ABI stability

[Hooman Mehr via swift-evolution]

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 
>  wrote:
> 
> 
>> On Jan 9, 2018, at 6:50 PM, Jon Hull via swift-evolution 
>> > wrote:
>> 
>>> On Jan 9, 2018, at 6:30 PM, Nevin Brackett-Rozinsky via swift-evolution 
>>> > 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

Re: [swift-evolution] Incremental ABI stability

[Greg Parker via swift-evolution]

> On Jan 9, 2018, at 6:50 PM, Jon Hull via swift-evolution 
>  wrote:
> 
>> On Jan 9, 2018, at 6:30 PM, Nevin Brackett-Rozinsky via swift-evolution 
>>  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

Re: [swift-evolution] Incremental ABI stability

[Jon Hull via swift-evolution]

+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 
>  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

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