ABI stability is an important feature which many Swift users are looking forward to. If I understand it correctly, once it’s here, the Standard Library becomes part of that ABI and only additive and backwards-compatible changes can be done. Seeing how we are still heavily modifying the Standard Library this year (Strings), wouldn’t it be wiser to let those changes simmer under the scrutiny of the broader community of Swift users for a year before we make it into the ABI?
ABI compatibility is important. Some projects need it, but I think that most projects (most Apple platform third-party applications) would only mildly benefit from it. But I want to make sure the Standard Library has had enough time to mature before we set it in stone.
With Swift 3, especially near the end, we had a bunch of changes that were rushed in because “we won’t have a chance to change it later, so let’s do it just in case”. I think setting these deadlines leads to worse choices overall.
That said, we do need stability so that we can start to build things that we know will last. I have ObjC programs which are years old and still work fine, but I have to update my Swift projects every 6 months to get them to compile.
What I would like to see instead of these deadlines for the whole language is for parts of the language to be stabilized over time. That is each part of the language and standard library would be marked one of the following:
• Unstable - This is in active development or is expected to have major changes soon. You can build things with it, but expect to have to update that code.
• Pre-stable - We have a design that we think works, and only expect minor tweaks, but we need to see how it works in the wild for a while before we know it is correct.
• Stable - This is a proven design that we feel comfortable baking in to the language. It has been tested in real world code and we are confident it won’t need to change in ways that break backward/forward compatibility.
Then each API would have this listed in the documentation. I think that the most we should start things at right now is “Pre-stable” given the pending updates from generics, concurrency, etc… that will affect wide swaths of the language.
For example, the new Arithmetic stuff would be Pre-stable because we think it will be our design, but we may have small tweaks once we see how it interacts with other API in the real world. Then if it works as well as we think it will, we can move it to Stable in the following release. String would be unstable right now due to the planned upgrades.
Breaking things up like this allows us to focus and take time on each part… baking things in as we are confident that they are the right choice. It also allows the developer community to plan accordingly and predict which parts of their code will need to be updated. I kind of feel like we are lying to ourselves with the current system.
Thanks,
Jon
···
On Jan 23, 2017, at 10:40 PM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
Hello swift-evolution,
ABI stability is an important feature which many Swift users are looking forward to. If I understand it correctly, once it’s here, the Standard Library becomes part of that ABI and only additive and backwards-compatible changes can be done. Seeing how we are still heavily modifying the Standard Library this year (Strings), wouldn’t it be wiser to let those changes simmer under the scrutiny of the broader community of Swift users for a year before we make it into the ABI?
ABI compatibility is important. Some projects need it, but I think that most projects (most Apple platform third-party applications) would only mildly benefit from it. But I want to make sure the Standard Library has had enough time to mature before we set it in stone.
Imho the major problem is that there's quite a lot confusion about what ABI stability actually means — and a lot uncertainty which proposals would actually affect it.
People with more insight may prove me wrong, but I'll lay out my understanding in the next paragraph:
It shouldn't be hard to have several versions of the stdlib installed, and no one talks about API stability (which is great as well — but a superior API imho is better ;-)
ABI is very low level and affects the junction of software and hardware (which bits are put into which location when a function call happens, utilisation of registers…).
I'm not really sure if the String-changes affect the ABI, but none the less, I strongly agree with your opinion that things shouldn't be done in a hurry, and I hope that Swift keeps the courage to break things for the better (sporadically ;-)
My apologies for being late to the thread — I've been away for the last week.
ABI stability remains a keystone goal for Swift, but the concerns you have here about not rushing important things are real. There's been a lot of scoping work into what ABI stability means, soup-to-nuts from the runtime to the Standard Library. As Michael Ilseman said he plans on sending out a manifesto shortly (possibly today) that includes a bunch of the scoping information for ABI stability. We also plan on having a dashboard up (probably on swift.org) that will allow the community to get a holistic view of the work on ABI stability and see the progress being made toward that goal. With that information we (the entire community) can make informed decisions on the priorities of specific ABI stability tasks and for Swift in general, and the relative tradeoffs being made. As Joe Groff said elsewhere in this thread some aspects of ABI are additive, and thus can be added later. When scoping ABI stability, we are trying to assess those kinds of lateral tradeoffs.
But as you point out, a lot of decisions get locked in once we have ABI stability. As part of that, we'll have some public discussion soon on when to open up "phase 2" (per Chris's email over the summer about goals for Swift 4) and what it means for Swift 4. I think a key goal for "phase 2" is to front load important design changes to Swift that may have implications on ABI.
Thank you for bringing up this topic. Let's continue this general discussion about ABI stability and what it means for prioritizing specific tasks for Swift once Michael has his manifesto out.
Ted
···
On Jan 23, 2017, at 10:40 PM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
Hello swift-evolution,
ABI stability is an important feature which many Swift users are looking forward to. If I understand it correctly, once it’s here, the Standard Library becomes part of that ABI and only additive and backwards-compatible changes can be done. Seeing how we are still heavily modifying the Standard Library this year (Strings), wouldn’t it be wiser to let those changes simmer under the scrutiny of the broader community of Swift users for a year before we make it into the ABI?
ABI compatibility is important. Some projects need it, but I think that most projects (most Apple platform third-party applications) would only mildly benefit from it. But I want to make sure the Standard Library has had enough time to mature before we set it in stone.
Imho the major problem is that there's quite a lot confusion about what ABI stability actually means — and a lot uncertainty which proposals would actually affect it.
I’m hoping to clarify this very soon with a lot more information.
People with more insight may prove me wrong, but I'll lay out my understanding in the next paragraph:
It shouldn't be hard to have several versions of the stdlib installed, and no one talks about API stability (which is great as well — but a superior API imho is better ;-)
ABI is very low level and affects the junction of software and hardware (which bits are put into which location when a function call happens, utilisation of registers…).
While ABI is low-level, at least in the sense that binary interfaces are low-level, a language’s ABI is actually pretty cross-cutting. All of a languages features and semantics that may be exposed across ABI boundaries need a place in the languages ABI, and Swift has a lot of features.
I'm not really sure if the String-changes affect the ABI, but none the less, I strongly agree with your opinion that things shouldn't be done in a hurry, and I hope that Swift keeps the courage to break things for the better (sporadically ;-)
One subtlety that’s not always brought up is that when we talk about stabilizing the Swift ABI, what is really important is stabilizing the interface of libSwiftCore. libSwiftCore includes the standard library and language runtime, so in a hand-wavy sense the stdlib’s API is part of libSwiftCore's ABI. Again, much more on this soon.
···
On Jan 24, 2017, at 12:12 AM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:
I'm not really sure if the String-changes affect the ABI, but none the less, I strongly agree with your opinion that things shouldn't be done in a hurry, and I hope that Swift keeps the courage to break things for the better (sporadically ;-)
I agree that we shouldn't rush decisions but I feel like the emphasis of
ABI stability has been a factor in discussing a number of proposals for
Swift 4 and has been a core goal of this next major release. Seems strange
to deemphasize it and its importance at this time.
Below are some thoughts from my perspective as someone involved in the
decision to adopt Swift in production at work.
*ABI Stability*
The reality is that stability in the ABI is important for a number of
developers and companies considering adopting or that have already adopted
Swift. Shipping the runtime increases the binary size of every app that
ships with it and becomes a barrier in user acquisition due to the
increased app size. If I'm not mistaken this issue multiplies as you add
extensions to your application since they all bundle the runtime
separately. Due to these issues, ABI Stability is one of the leading
reasons we have not adopted Swift in our flagship app.
*API Stability*
This I would consider just as important as the ABI stability. Changing APIs
provides a lot of churn on developers that manage large codebases and I've
often heard of issues using the Swift migrator at scale which doesn't help.
I'd like to see a less drastic approach like Jonathan is suggesting where
we have clear indication of APIs that might change or at least allowing one
minor release where an API will warn if it's used but is still available to
allow developers time to migrate.
Right now I think it's important to keep ABI stability as a core tenant of
any proposal and acknowledge that we need to just flag how proposals will
affect ABI stability. This seems inline with our stance on the development
of a Rust-inspired `Memory Ownership Model`: "While a full memory ownership
model is likely too large for Swift 4 stage 1, we need a comprehensive
design to understand how it will change the ABI."
···
On Tue, Jan 24, 2017 at 3:16 AM, Georgios Moschovitis via swift-evolution < swift-evolution@swift.org> wrote:
> I'm not really sure if the String-changes affect the ABI, but none the
less, I strongly agree with your opinion that things shouldn't be done in a
hurry, and I hope that Swift keeps the courage to break things for the
better (sporadically ;-)
I do not see how you can consider standardizing ABI without first standardizing the dynamic features and the desired programmatic interfaces to them.
We know that dynamic features need to come. They will impact everything. My personal ideal is a language that smoothly transitions from fully dynamic to fully static without a lot of fuss.
···
On Jan 24, 2017, at 11:45, Rahul Malik via swift-evolution <swift-evolution@swift.org> wrote:
I agree that we shouldn't rush decisions but I feel like the emphasis of ABI stability has been a factor in discussing a number of proposals for Swift 4 and has been a core goal of this next major release. Seems strange to deemphasize it and its importance at this time.
Below are some thoughts from my perspective as someone involved in the decision to adopt Swift in production at work.
ABI Stability
The reality is that stability in the ABI is important for a number of developers and companies considering adopting or that have already adopted Swift. Shipping the runtime increases the binary size of every app that ships with it and becomes a barrier in user acquisition due to the increased app size. If I'm not mistaken this issue multiplies as you add extensions to your application since they all bundle the runtime separately. Due to these issues, ABI Stability is one of the leading reasons we have not adopted Swift in our flagship app.
API Stability
This I would consider just as important as the ABI stability. Changing APIs provides a lot of churn on developers that manage large codebases and I've often heard of issues using the Swift migrator at scale which doesn't help. I'd like to see a less drastic approach like Jonathan is suggesting where we have clear indication of APIs that might change or at least allowing one minor release where an API will warn if it's used but is still available to allow developers time to migrate.
Right now I think it's important to keep ABI stability as a core tenant of any proposal and acknowledge that we need to just flag how proposals will affect ABI stability. This seems inline with our stance on the development of a Rust-inspired `Memory Ownership Model`: "While a full memory ownership model is likely too large for Swift 4 stage 1, we need a comprehensive design to understand how it will change the ABI."
On Tue, Jan 24, 2017 at 3:16 AM, Georgios Moschovitis via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> I'm not really sure if the String-changes affect the ABI, but none the less, I strongly agree with your opinion that things shouldn't be done in a hurry, and I hope that Swift keeps the courage to break things for the better (sporadically ;-)
There will inevitably be features at some point that require added runtime support that won't backward-deploy to older runtime versions. However, a lot of the information you'd need for many dynamic features is already there, and planned to be stabilized as part of the ABI. We already emit reflection data that describes the physical layouts of types, and once those formats are stabilized, building a library that interprets the metadata is additive (and could conceivably be done by a third party independent of the standard library). There may not be metadata for individual methods yet, but there is tracking of protocol conformances, and once the standard library protocols are stabilized, someone could make assumptions about the protocol witness table layouts for those protocols to find particular method implementations even if you're running on an older standard library without the full method metadata we might support one day.
-Joe
···
On Jan 24, 2017, at 12:15 PM, Freak Show via swift-evolution <swift-evolution@swift.org> wrote:
I do not see how you can consider standardizing ABI without first standardizing the dynamic features and the desired programmatic interfaces to them.
We know that dynamic features need to come. They will impact everything. My personal ideal is a language that smoothly transitions from fully dynamic to fully static without a lot of fuss.
This is both great to hear (ivar introspection available) and a little disappointing (method level not). Basically, I would hope for at least enough to allow implementation of KVC - which would require the ability to find and invoke methods by name.
···
On Jan 24, 2017, at 14:16, Joe Groff <jgroff@apple.com> wrote:
a lot of the information you'd need for many dynamic features is already there, and planned to be stabilized as part of the ABI. We already emit reflection data that describes the physical layouts of types, and once those formats are stabilized, building a library that interprets the metadata is additive (and could conceivably be done by a third party independent of the standard library). There may not be metadata for individual methods yet
I'm also late to the thread (and the ABI stability discussion in general). Is there a reference online that describes the reason for desiring ABI stability? I mean, I get, generally, why we need it. But I'd like to see the arguments for why we need it *now*, before certain other things are in place. Not saying the reasons for the urgency aren't valid, I just don't know what they are.
Thanks!
···
On Jan 25, 2017, at 08:44 , Freak Show via swift-evolution <swift-evolution@swift.org> wrote:
This is both great to hear (ivar introspection available) and a little disappointing (method level not). Basically, I would hope for at least enough to allow implementation of KVC - which would require the ability to find and invoke methods by name.
On Jan 24, 2017, at 14:16, Joe Groff <jgroff@apple.com> wrote:
a lot of the information you'd need for many dynamic features is already there, and planned to be stabilized as part of the ABI. We already emit reflection data that describes the physical layouts of types, and once those formats are stabilized, building a library that interprets the metadata is additive (and could conceivably be done by a third party independent of the standard library). There may not be metadata for individual methods yet
As described in e.g. https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md#what-does-abi-stability-enable, it primarily enables OSes to ship with a copy of the standard library and runtime, rather than every app having to bundle their own copy. It’s also a crucial piece of supporting 3rd party frameworks. There are also more subtle benefits such as the de-coupling of developer tools that work with Swift binaries (e.g. debuggers and profilers). Some of the tasks towards stability are performance improvements we want to do anyways.
···
On Jan 25, 2017, at 1:36 PM, Rick Mann via swift-evolution <swift-evolution@swift.org> wrote:
I'm also late to the thread (and the ABI stability discussion in general). Is there a reference online that describes the reason for desiring ABI stability? I mean, I get, generally, why we need it. But I'd like to see the arguments for why we need it *now*, before certain other things are in place. Not saying the reasons for the urgency aren't valid, I just don't know what they are.
Thanks!
On Jan 25, 2017, at 08:44 , Freak Show via swift-evolution <swift-evolution@swift.org> wrote:
This is both great to hear (ivar introspection available) and a little disappointing (method level not). Basically, I would hope for at least enough to allow implementation of KVC - which would require the ability to find and invoke methods by name.
On Jan 24, 2017, at 14:16, Joe Groff <jgroff@apple.com> wrote:
a lot of the information you'd need for many dynamic features is already there, and planned to be stabilized as part of the ABI. We already emit reflection data that describes the physical layouts of types, and once those formats are stabilized, building a library that interprets the metadata is additive (and could conceivably be done by a third party independent of the standard library). There may not be metadata for individual methods yet
My concern, of course, is the obvious one: that we'll have to compromise on future functionality in order to not break ABI compatibility, or we'll have a painful transition when we do break it. While today it's suboptimal to ship copies of the runtime with each application, it's a working solution.
I'd really like to make sure Swift can be fully introspective (soon), but I don't know how easy it will be to add that after the ABI is locked down. Maybe I'm just being alarmist. I'd also like to see the ability to replace code at run time.
If all that is already accommodated by the current ABI, then I'm satisfied. But it seems like there's some concern about this, and I worry that locking down the ABI too early will make those additions MUCH harder in the future.
Thanks!
···
On Jan 25, 2017, at 15:09 , Michael Ilseman <milseman@apple.com> wrote:
As described in e.g. https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md#what-does-abi-stability-enable, it primarily enables OSes to ship with a copy of the standard library and runtime, rather than every app having to bundle their own copy. It’s also a crucial piece of supporting 3rd party frameworks. There are also more subtle benefits such as the de-coupling of developer tools that work with Swift binaries (e.g. debuggers and profilers). Some of the tasks towards stability are performance improvements we want to do anyways.
On Jan 25, 2017, at 1:36 PM, Rick Mann via swift-evolution <swift-evolution@swift.org> wrote:
I'm also late to the thread (and the ABI stability discussion in general). Is there a reference online that describes the reason for desiring ABI stability? I mean, I get, generally, why we need it. But I'd like to see the arguments for why we need it *now*, before certain other things are in place. Not saying the reasons for the urgency aren't valid, I just don't know what they are.
Thanks!
On Jan 25, 2017, at 08:44 , Freak Show via swift-evolution <swift-evolution@swift.org> wrote:
This is both great to hear (ivar introspection available) and a little disappointing (method level not). Basically, I would hope for at least enough to allow implementation of KVC - which would require the ability to find and invoke methods by name.
On Jan 24, 2017, at 14:16, Joe Groff <jgroff@apple.com> wrote:
a lot of the information you'd need for many dynamic features is already there, and planned to be stabilized as part of the ABI. We already emit reflection data that describes the physical layouts of types, and once those formats are stabilized, building a library that interprets the metadata is additive (and could conceivably be done by a third party independent of the standard library). There may not be metadata for individual methods yet
Thanks Michael for the manifesto. It definitely made quite a few things clearer for me.
Concerning the topic of when ABI stability should happen, I still have a strong feelings that Swift 4 might not be the best time for it. Concerning Data Layout, Type Metadata, Mangling, the Calling Convention and the Runtime, I don’t know enough about them to comment. I’m really centring my discussion on the Standard Library.
If we look back at the evolution of the Standard Library for Swift 3, they were many changes. And I’m personally very happy with the thoughtful design that went into those. But they are still a few gotchas, which is to be expected when so many changes are made at once. But we only discover them once the thousands of Swift developers start using those APIs.
I just worry that all the big changes that will come for Swift 4 won’t have time to mature. Furthermore, it seems like several extra compiler features which won’t happen in Swift 4 are really necessary to simplify the Standard Library surface area. I’m specifically thinking of type constraints on Existentials which would allow us to get rid of all the Any* structs and replace them with typedefs. But I’m sure there are more examples like those which are just waiting for the generics to become powerful enough to express APIs more elegantly.
Perhaps someone from the Standard Library team can chime in to give us their opinion on this topic.
Thanks!
David.
···
On 26 Jan 2017, at 00:09, Michael Ilseman via swift-evolution <swift-evolution@swift.org> wrote:
As described in e.g. https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md#what-does-abi-stability-enable, it primarily enables OSes to ship with a copy of the standard library and runtime, rather than every app having to bundle their own copy. It’s also a crucial piece of supporting 3rd party frameworks. There are also more subtle benefits such as the de-coupling of developer tools that work with Swift binaries (e.g. debuggers and profilers). Some of the tasks towards stability are performance improvements we want to do anyways.
On Jan 25, 2017, at 1:36 PM, Rick Mann via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I'm also late to the thread (and the ABI stability discussion in general). Is there a reference online that describes the reason for desiring ABI stability? I mean, I get, generally, why we need it. But I'd like to see the arguments for why we need it *now*, before certain other things are in place. Not saying the reasons for the urgency aren't valid, I just don't know what they are.
Thanks!
On Jan 25, 2017, at 08:44 , Freak Show via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
This is both great to hear (ivar introspection available) and a little disappointing (method level not). Basically, I would hope for at least enough to allow implementation of KVC - which would require the ability to find and invoke methods by name.
On Jan 24, 2017, at 14:16, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:
a lot of the information you'd need for many dynamic features is already there, and planned to be stabilized as part of the ABI. We already emit reflection data that describes the physical layouts of types, and once those formats are stabilized, building a library that interprets the metadata is additive (and could conceivably be done by a third party independent of the standard library). There may not be metadata for individual methods yet
I have had exactly the same worry for quite some time. We're still
waiting for many basic components of the generics system, and, if our
experience with protocol extensions is any guide, before we have those
features in hand, it will be impossible to anticipate the design changes
we'd want to make to the standard library... and that cuts against the
grain of *source* (to say nothing of ABI) stability.
So far I've been unable to form a mental model for what source and/or
ABI stability actually means for our ability to make changes to the
standard library in the future. It's possible that we discover a
workable path forward, but it's equally possible that we find ourselves
painted into a corner.
···
on Thu Jan 26 2017, David Hart <swift-evolution@swift.org> wrote:
Thanks Michael for the manifesto. It definitely made quite a few things clearer for me.
Concerning the topic of when ABI stability should happen, I still have
a strong feelings that Swift 4 might not be the best time for
it. Concerning Data Layout, Type Metadata, Mangling, the Calling
Convention and the Runtime, I don’t know enough about them to
comment. I’m really centring my discussion on the Standard Library.
If we look back at the evolution of the Standard Library for Swift 3,
they were many changes. And I’m personally very happy with the
thoughtful design that went into those. But they are still a few
gotchas, which is to be expected when so many changes are made at
once. But we only discover them once the thousands of Swift developers
start using those APIs.
I just worry that all the big changes that will come for Swift 4 won’t
have time to mature. Furthermore, it seems like several extra compiler
features which won’t happen in Swift 4 are really necessary to
simplify the Standard Library surface area. I’m specifically thinking
of type constraints on Existentials which would allow us to get rid of
all the Any* structs and replace them with typedefs. But I’m sure
there are more examples like those which are just waiting for the
generics to become powerful enough to express APIs more elegantly.
Perhaps someone from the Standard Library team can chime in to give us
their opinion on this topic.
On a scale of "trivial" to "impossible", how difficult would it be to have a mechanism for telling the compiler how to translate between major versions of the ABI/stdlib? Could we ship app/libs with a small "shim" library for backwards compatibility, if we had to? I mean it wouldn't be ideal, but if it's possible, "works" is better than either "doesn't work" or "painted into a corner", isn't it?
(In any case, this seems like a last resort... I bring it up not as a "proper" solution, but as a possible "emergency" way out, if we realize in 2-3 years that we locked some things down too soon.)
- Dave Sweeris
···
On Jan 26, 2017, at 13:02, Rick Mann via swift-evolution <swift-evolution@swift.org> wrote:
Thanks for that, that's helpful.
My concern, of course, is the obvious one: that we'll have to compromise on future functionality in order to not break ABI compatibility, or we'll have a painful transition when we do break it. While today it's suboptimal to ship copies of the runtime with each application, it's a working solution.
I'd really like to make sure Swift can be fully introspective (soon), but I don't know how easy it will be to add that after the ABI is locked down. Maybe I'm just being alarmist. I'd also like to see the ability to replace code at run time.
If all that is already accommodated by the current ABI, then I'm satisfied. But it seems like there's some concern about this, and I worry that locking down the ABI too early will make those additions MUCH harder in the future.
Thanks Michael for the manifesto. It definitely made quite a few things clearer for me.
Concerning the topic of when ABI stability should happen, I still have a strong feelings that Swift 4 might not be the best time for it. Concerning Data Layout, Type Metadata, Mangling, the Calling Convention and the Runtime, I don’t know enough about them to comment. I’m really centring my discussion on the Standard Library.
If we look back at the evolution of the Standard Library for Swift 3, they were many changes. And I’m personally very happy with the thoughtful design that went into those. But they are still a few gotchas, which is to be expected when so many changes are made at once. But we only discover them once the thousands of Swift developers start using those APIs.
I just worry that all the big changes that will come for Swift 4 won’t have time to mature. Furthermore, it seems like several extra compiler features which won’t happen in Swift 4 are really necessary to simplify the Standard Library surface area. I’m specifically thinking of type constraints on Existentials which would allow us to get rid of all the Any* structs and replace them with typedefs. But I’m sure there are more examples like those which are just waiting for the generics to become powerful enough to express APIs more elegantly.
Perhaps someone from the Standard Library team can chime in to give us their opinion on this topic.
I definitely share the concern about locking down ABI before:
1) The language has the features required for the preferred standard library design.
2) The standard library team has had enough time and experience to be confident in the design of all aspects of the standard library which are frozen when ABI is frozen.
One of the things I have appreciated most about Swift is the commitment to making the right decisions for the long term. It’s important that we don’t get locked into decisions in the standard library that don’t align with the most desirable long term design.
Locking down ABI when all foreseeable desirable changes are additive is one thing. But doing so before we get there feels premature.
···
On Jan 26, 2017, at 2:12 PM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
Thanks!
David.
On 26 Jan 2017, at 00:09, Michael Ilseman via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
As described in e.g. https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md#what-does-abi-stability-enable, it primarily enables OSes to ship with a copy of the standard library and runtime, rather than every app having to bundle their own copy. It’s also a crucial piece of supporting 3rd party frameworks. There are also more subtle benefits such as the de-coupling of developer tools that work with Swift binaries (e.g. debuggers and profilers). Some of the tasks towards stability are performance improvements we want to do anyways.
On Jan 25, 2017, at 1:36 PM, Rick Mann via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I'm also late to the thread (and the ABI stability discussion in general). Is there a reference online that describes the reason for desiring ABI stability? I mean, I get, generally, why we need it. But I'd like to see the arguments for why we need it *now*, before certain other things are in place. Not saying the reasons for the urgency aren't valid, I just don't know what they are.
Thanks!
On Jan 25, 2017, at 08:44 , Freak Show via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
This is both great to hear (ivar introspection available) and a little disappointing (method level not). Basically, I would hope for at least enough to allow implementation of KVC - which would require the ability to find and invoke methods by name.
On Jan 24, 2017, at 14:16, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:
a lot of the information you'd need for many dynamic features is already there, and planned to be stabilized as part of the ABI. We already emit reflection data that describes the physical layouts of types, and once those formats are stabilized, building a library that interprets the metadata is additive (and could conceivably be done by a third party independent of the standard library). There may not be metadata for individual methods yet
Thanks Michael for the manifesto. It definitely made quite a few things clearer for me.
Concerning the topic of when ABI stability should happen, I still have
a strong feelings that Swift 4 might not be the best time for
it. Concerning Data Layout, Type Metadata, Mangling, the Calling
Convention and the Runtime, I don’t know enough about them to
comment. I’m really centring my discussion on the Standard Library.
If we look back at the evolution of the Standard Library for Swift 3,
they were many changes. And I’m personally very happy with the
thoughtful design that went into those. But they are still a few
gotchas, which is to be expected when so many changes are made at
once. But we only discover them once the thousands of Swift developers
start using those APIs.
I just worry that all the big changes that will come for Swift 4 won’t
have time to mature. Furthermore, it seems like several extra compiler
features which won’t happen in Swift 4 are really necessary to
simplify the Standard Library surface area. I’m specifically thinking
of type constraints on Existentials which would allow us to get rid of
all the Any* structs and replace them with typedefs. But I’m sure
there are more examples like those which are just waiting for the
generics to become powerful enough to express APIs more elegantly.
Perhaps someone from the Standard Library team can chime in to give us
their opinion on this topic.
I have had exactly the same worry for quite some time. We're still
waiting for many basic components of the generics system, and, if our
experience with protocol extensions is any guide, before we have those
features in hand, it will be impossible to anticipate the design changes
we'd want to make to the standard library... and that cuts against the
grain of *source* (to say nothing of ABI) stability.
So far I've been unable to form a mental model for what source and/or
ABI stability actually means for our ability to make changes to the
standard library in the future. It's possible that we discover a
workable path forward, but it's equally possible that we find ourselves
painted into a corner.
I hope we can all agree that the last thing we want to do is get painted into a corner. IMO we should be very sure that won’t happen before making a firm commitment to lock down ABI stability.
···
On Jan 26, 2017, at 3:10 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Thu Jan 26 2017, David Hart <swift-evolution@swift.org> wrote:
My concern, of course, is the obvious one: that we'll have to compromise on future functionality in order to not break ABI compatibility, or we'll have a painful transition when we do break it. While today it's suboptimal to ship copies of the runtime with each application, it's a working solution.
I don’t disagree with your overall point, but I do want to emphasize that forcing apps to bundle the stdlib and runtime is more than just suboptimal. For many companies, increasing the OTA download size has real financial impact as it can affect whether new users are willing to download an app, as well as whether they will wait for it to download and install.
That being said, I hope that many of the ABI stability tasks[2] also result in smaller binary sizes for applications. They should be prioritized highly no matter when stability happens.
I'd really like to make sure Swift can be fully introspective (soon), but I don't know how easy it will be to add that after the ABI is locked down. Maybe I'm just being alarmist. I'd also like to see the ability to replace code at run time.
New runtime APIs are ABI-additive. It’s likely that much of Swift’s already extensive type metadata will be kept opaque[1] to allow the language to continue to grow and change, and new entries can be added.
If all that is already accommodated by the current ABI, then I'm satisfied. But it seems like there's some concern about this, and I worry that locking down the ABI too early will make those additions MUCH harder in the future.
Locking down the standard library API and (some) exposed implementation details is certainly a scary aspect of ABI stability.
On Jan 26, 2017, at 1:02 PM, Rick Mann via swift-evolution <swift-evolution@swift.org> wrote:
Thanks!
On Jan 25, 2017, at 15:09 , Michael Ilseman <milseman@apple.com> wrote:
As described in e.g. https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md#what-does-abi-stability-enable, it primarily enables OSes to ship with a copy of the standard library and runtime, rather than every app having to bundle their own copy. It’s also a crucial piece of supporting 3rd party frameworks. There are also more subtle benefits such as the de-coupling of developer tools that work with Swift binaries (e.g. debuggers and profilers). Some of the tasks towards stability are performance improvements we want to do anyways.
On Jan 25, 2017, at 1:36 PM, Rick Mann via swift-evolution <swift-evolution@swift.org> wrote:
I'm also late to the thread (and the ABI stability discussion in general). Is there a reference online that describes the reason for desiring ABI stability? I mean, I get, generally, why we need it. But I'd like to see the arguments for why we need it *now*, before certain other things are in place. Not saying the reasons for the urgency aren't valid, I just don't know what they are.
Thanks!
On Jan 25, 2017, at 08:44 , Freak Show via swift-evolution <swift-evolution@swift.org> wrote:
This is both great to hear (ivar introspection available) and a little disappointing (method level not). Basically, I would hope for at least enough to allow implementation of KVC - which would require the ability to find and invoke methods by name.
On Jan 24, 2017, at 14:16, Joe Groff <jgroff@apple.com> wrote:
a lot of the information you'd need for many dynamic features is already there, and planned to be stabilized as part of the ABI. We already emit reflection data that describes the physical layouts of types, and once those formats are stabilized, building a library that interprets the metadata is additive (and could conceivably be done by a third party independent of the standard library). There may not be metadata for individual methods yet
I fully agree that locking down the ABI prematurely would be detrimental to the long-term future of the language.
Part of the point of the ABI manifesto is to scope out what are the desirable or critical changes needed before ABI gets locked down. From that we can have concrete discussions on what’s left to be done, how much work it will take to get there, etc.
···
On Jan 26, 2017, at 12:19 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
Locking down ABI when all foreseeable desirable changes are additive is one thing. But doing so before we get there feels premature.