Locking down ABI when all foreseeable desirable changes are additive is one thing. But doing so before we get there feels premature.
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.
That makes perfect sense.
One thing that isn't clear in the manifesto that I think a lot of us are wondering about is what language features are important to the long-term desired design of the standard library that aren't in place yet? There has been some informal discussion of this on the list but nothing more and it hasn't been clear whether those features will be ready by the time ABI stability is locked down. Maybe the manifesto is a good place to start documenting more formally the language features needed to realize the desired design of the standard library APIs that will be present when the ABI is declared stable.
There’s a bit of a chicken-and-the-egg problem here, where the stdlib will discover better APIs after playing with new language features. This is one of the reasons for the intense focus in Swift 4 phase 1.
···
On Jan 26, 2017, at 5:48 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 26, 2017, at 7:29 PM, Ted Kremenek <kremenek@apple.com <mailto:kremenek@apple.com>> wrote:
On Jan 26, 2017, at 12:19 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto: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.
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.
That makes perfect sense.
One thing that isn't clear in the manifesto that I think a lot of us are wondering about is what language features are important to the long-term desired design of the standard library that aren't in place yet? There has been some informal discussion of this on the list but nothing more and it hasn't been clear whether those features will be ready by the time ABI stability is locked down. Maybe the manifesto is a good place to start documenting more formally the language features needed to realize the desired design of the standard library APIs that will be present when the ABI is declared stable.
···
Sent from my iPad
On Jan 26, 2017, at 7:29 PM, Ted Kremenek <kremenek@apple.com> wrote:
On Jan 26, 2017, at 12:19 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
Unfortunately, even source stability (which is generally a weaker
constraint than ABI stability) can have the corner-painting effect, and
you really have to weigh that downside off against the cost of breaking
people's code when they upgrade their Swift version. IIUC that has been
a major pain point for many people.
···
on Thu Jan 26 2017, Matthew Johnson <swift-evolution@swift.org> wrote:
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:
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.
In a way some people moved to a new language with few years of life under its belt and should kind of expect the language not offering the stability and maturity something tested and developed over many years like Objective-C provides.
As mean as that may sound (not trying to be), are the needs of the language and medium term users listened to because of people moving critical production code before it was time?
Sent from my iPhone
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.
Unfortunately, even source stability (which is generally a weaker
constraint than ABI stability) can have the corner-painting effect, and
you really have to weigh that downside off against the cost of breaking
people's code when they upgrade their Swift version. IIUC that has been
a major pain point for many people.
On 27 Jan 2017, at 07:04, Goffredo Marocchi <panajev@gmail.com> wrote:
On 27 Jan 2017, at 03:48, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Thu Jan 26 2017, Matthew Johnson <swift-evolution@swift.org> wrote:
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:
Locking down ABI when all foreseeable desirable changes are additive is one thing. But doing so before we get there feels premature.
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.
That makes perfect sense.
One thing that isn't clear in the manifesto that I think a lot of us are wondering about is what language features are important to the long-term desired design of the standard library that aren't in place yet? There has been some informal discussion of this on the list but nothing more and it hasn't been clear whether those features will be ready by the time ABI stability is locked down. Maybe the manifesto is a good place to start documenting more formally the language features needed to realize the desired design of the standard library APIs that will be present when the ABI is declared stable.
There’s a bit of a chicken-and-the-egg problem here, where the stdlib will discover better APIs after playing with new language features. This is one of the reasons for the intense focus in Swift 4 phase 1.
Yes of course. But I imagine we could come up with a reasonable list of language features that we *think* would have an impact on the library APIs that exist today.
···
On Jan 26, 2017, at 8:22 PM, Michael Ilseman <milseman@apple.com> wrote:
On Jan 26, 2017, at 5:48 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jan 26, 2017, at 7:29 PM, Ted Kremenek <kremenek@apple.com <mailto:kremenek@apple.com>> wrote:
On Jan 26, 2017, at 12:19 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto: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.
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.
Unfortunately, even source stability (which is generally a weaker
constraint than ABI stability) can have the corner-painting effect, and
you really have to weigh that downside off against the cost of breaking
people's code when they upgrade their Swift version. IIUC that has been
a major pain point for many people.
Yes, for sure. I just don’t want to see us end up with baggage in the long run because we made promises when foreseeable changes were still on the horizon.
Swift 3 migration has definitely caused some pain. For a small to moderate sized app with a small team it is kind of annoying not really that bad (a couple days tops). For larger apps with larger teams it is pretty disruptive. I’ll be part of the migration effort for a fairly large app in the near future. I’m really interested to see how that migration plays out.
I imagine future source breaking changes will be much more modest and we will have a better story around dependencies so I expect the pain will be significantly less. We will also have the experience of the Swift 3 migration which will help in weighing what the real world cost of specific proposed changes might be.
···
On Jan 26, 2017, at 9:48 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Thu Jan 26 2017, Matthew Johnson <swift-evolution@swift.org> wrote:
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:
On Jan 26, 2017, at 13:14, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 26, 2017, at 3:10 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
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.
Depends on the differences between versions. Some changes are plausible to patch retroactively, but for most changes it is next to impossible.
In general each ABI detail is locked down because there are compiled instructions that depend on it. To a close approximation existing compiled instructions cannot be changed. (Compiled instructions are hard to analyze. Compiled instructions are hard to rearrange without throwing off things like code<->code and code<->data offsets. Compiled instructions are often part of the OS or codesigned.)
···
On Jan 26, 2017, at 2:15 PM, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:
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.
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.)
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.
Wouldn't it be possible to have several versions of the runtime bundled with the OS? Frameworks on macOS still have a filesystem layout that is build around the idea of having several versions in one bundle.
Also, breaking ABI isn't that uncommon: C++ did so in the past (and imho that language did things that are worse ;-)
I guess the problem is at least partly a phycological one:
ABI stability was supposed to be one major feature of Swift 3, and it's somewhat depressing when big goals are delayed over and over.
Maybe you could "stabilise" the ABI temporarily, and plan for a breaking change in two or three years, when the dust has settled?
Doing so would reduce the pressure, and long-term Mac developers are used to huge breaking changes anyway ;-)
It could also free resources to work on features and ideas that help to realise shortcomings worth to be addressed in a "really stable" ABI.
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.
Wouldn't it be possible to have several versions of the runtime bundled with the OS? Frameworks on macOS still have a filesystem layout that is build around the idea of having several versions in one bundle.
Also, breaking ABI isn't that uncommon: C++ did so in the past (and imho that language did things that are worse ;-)
I guess the problem is at least partly a phycological one:
ABI stability was supposed to be one major feature of Swift 3, and it's somewhat depressing when big goals are delayed over and over.
Maybe you could "stabilise" the ABI temporarily, and plan for a breaking change in two or three years, when the dust has settled?
Doing so would reduce the pressure, and long-term Mac developers are used to huge breaking changes anyway ;-)
It could also free resources to work on features and ideas that help to realise shortcomings worth to be addressed in a "really stable" ABI.
[have to remember to write something for the "switch to Discourse"-thread — seems this message got lost]
Yup. If the root of all evil for programming is premature optimization, the root of all evil for design is premature standardization.
Thanks,
Jon
···
On Jan 27, 2017, at 5:54 PM, Matt Whiteside via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 26, 2017, at 13:14, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 26, 2017, at 3:10 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
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.
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.
Wouldn't it be possible to have several versions of the runtime bundled with the OS? Frameworks on macOS still have a filesystem layout that is build around the idea of having several versions in one bundle.
I have personally thought about this as well, but it would also mean that the OS frameworks would need to come in several versions - imagine the following scenario:
Swift 4 libraries are included with macOS 10.13, some frameworks in the system link against them (e.g. AppKit).
Then, with macOS 10.14, Swift 5 comes along with ABI incompatible changes. AFAICT, if you want apps written compiled with Swift 4 to work under 10.14, you'll need:
- runtime libraries for Swift 4
- all system frameworks will need to contain two variants - one compatible with Swift 4 and one with Swift 5. This is IMHO absolutely unmaintainable in the long run. For how long would you need to keep several versions of the framework around? What happens when Swift 6 comes along with another breaking changes? Would each system framework have 3 versions embedded?
···
On Jan 27, 2017, at 11:35 AM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:
Also, breaking ABI isn't that uncommon: C++ did so in the past (and imho that language did things that are worse ;-)
I guess the problem is at least partly a phycological one:
ABI stability was supposed to be one major feature of Swift 3, and it's somewhat depressing when big goals are delayed over and over.
Maybe you could "stabilise" the ABI temporarily, and plan for a breaking change in two or three years, when the dust has settled?
Doing so would reduce the pressure, and long-term Mac developers are used to huge breaking changes anyway ;-)
It could also free resources to work on features and ideas that help to realise shortcomings worth to be addressed in a "really stable" ABI.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
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.
Wouldn't it be possible to have several versions of the runtime bundled with the OS? Frameworks on macOS still have a filesystem layout that is build around the idea of having several versions in one bundle.
I have personally thought about this as well, but it would also mean that the OS frameworks would need to come in several versions - imagine the following scenario:
Swift 4 libraries are included with macOS 10.13, some frameworks in the system link against them (e.g. AppKit).
Then, with macOS 10.14, Swift 5 comes along with ABI incompatible changes. AFAICT, if you want apps written compiled with Swift 4 to work under 10.14, you'll need:
- runtime libraries for Swift 4
- all system frameworks will need to contain two variants - one compatible with Swift 4 and one with Swift 5. This is IMHO absolutely unmaintainable in the long run. For how long would you need to keep several versions of the framework around? What happens when Swift 6 comes along with another breaking changes? Would each system framework have 3 versions embedded?
That's right. If the OS frameworks use Swift then either (1) you have to clone the framework stack for each Swift version, or (2) you have only one copy of the frameworks but frameworks and apps can't share their Swift objects or publish Swift API.
The framework structure that Apple inherited from NeXT supports framework versioning, but *no frameworks use it*. It doesn't scale.
(NeXT used framework versioning a few times, back when the entire OS only had a handful of frameworks. Today's AppKit and Foundation are version C. libSystem is version B. That's about it.)
Also, breaking ABI isn't that uncommon: C++ did so in the past (and imho that language did things that are worse ;-)
Note that Apple's OS frameworks do not export C++ interfaces. One reason was exactly that historically-unstable C++ ABI. Apple's OS developers chose #2 above for C++. OS frameworks and apps could get away with mismatched C++ ABI because they don't pass C++ objects to each other.
···
On Jan 27, 2017, at 2:57 AM, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 27, 2017, at 11:35 AM, Tino Heth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
- runtime libraries for Swift 4
- all system frameworks will need to contain two variants - one compatible with Swift 4 and one with Swift 5. This is IMHO absolutely unmaintainable in the long run. For how long would you need to keep several versions of the framework around? What happens when Swift 6 comes along with another breaking changes? Would each system framework have 3 versions embedded?
That's right. If the OS frameworks use Swift then either (1) you have to clone the framework stack for each Swift version, or (2) you have only one copy of the frameworks but frameworks and apps can't share their Swift objects or publish Swift API.
The framework structure that Apple inherited from NeXT supports framework versioning, but *no frameworks use it*. It doesn't scale.
sure, it's preferable to have a single version that works with all apps — but if it's technically possible to have one clone installed with the OS, isn't that better than one version for each app?
Managing several versions shouldn't be that hard (have a look at https://nixos.org/nix/\).
I completely agree with ABI stability goal…I only have a fear regarding some postponed evolutions requests especially Abstract Classes. Would it be still possible ?
David Scrève
···
> On Jan 27, 2017, at 2:57 AM, Charlie Monroe via swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
>
That's right. If the OS frameworks use Swift then either (1) you have to clone the framework stack for each Swift version, or (2) you have only one copy of the frameworks but frameworks and apps can't share their Swift objects or publish Swift API.
The framework structure that Apple inherited from NeXT supports framework versioning, but *no frameworks use it*. It doesn't scale.
(NeXT used framework versioning a few times, back when the entire OS only had a handful of frameworks. Today's AppKit and Foundation are version C. libSystem is version B. That's about it.)
It would mean for Apple (and others who'd distribute compiled frameworks) to maintain several code bases of the same framework given that they would need to maintain backward compatibility and hence wouldn't be able to use new language features, etc. It's IMHO not that much about the technical constraint of having multiple binaries within the framework bundle as much as maintaining the code in a way that would compile under all Swift versions you'd like to support.
···
On Jan 27, 2017, at 5:43 PM, Tino Heth <2th@gmx.de> wrote:
- runtime libraries for Swift 4
- all system frameworks will need to contain two variants - one compatible with Swift 4 and one with Swift 5. This is IMHO absolutely unmaintainable in the long run. For how long would you need to keep several versions of the framework around? What happens when Swift 6 comes along with another breaking changes? Would each system framework have 3 versions embedded?
That's right. If the OS frameworks use Swift then either (1) you have to clone the framework stack for each Swift version, or (2) you have only one copy of the frameworks but frameworks and apps can't share their Swift objects or publish Swift API.
The framework structure that Apple inherited from NeXT supports framework versioning, but *no frameworks use it*. It doesn't scale.
sure, it's preferable to have a single version that works with all apps — but if it's technically possible to have one clone installed with the OS, isn't that better than one version for each app?
Managing several versions shouldn't be that hard (have a look at https://nixos.org/nix/\).
Rather than Apple have to commit in perpetuity to ship all relevant versions of the frameworks, one could imagine more of an app-thinning/install-time optimization: “thinned” versions of apps would be built and signed without the shared system frameworks, but with dependency information recorded. At install-time, the app would be installed, and the working set of required shared frameworks on the device would be updated with any needed dependent frameworks. Thus the only the set of frameworks required by installed apps would be present on device.
This would require more app store, install-time, and perhaps dynamic linking, infrastructure, but would seem to solve the problem in a way that wouldn’t require ongoing development resources be applied to old versions.
James
···
On Jan 27, 2017, at 8:59 AM, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 27, 2017, at 5:43 PM, Tino Heth <2th@gmx.de <mailto:2th@gmx.de>> wrote:
- runtime libraries for Swift 4
- all system frameworks will need to contain two variants - one compatible with Swift 4 and one with Swift 5. This is IMHO absolutely unmaintainable in the long run. For how long would you need to keep several versions of the framework around? What happens when Swift 6 comes along with another breaking changes? Would each system framework have 3 versions embedded?
That's right. If the OS frameworks use Swift then either (1) you have to clone the framework stack for each Swift version, or (2) you have only one copy of the frameworks but frameworks and apps can't share their Swift objects or publish Swift API.
The framework structure that Apple inherited from NeXT supports framework versioning, but *no frameworks use it*. It doesn't scale.
sure, it's preferable to have a single version that works with all apps — but if it's technically possible to have one clone installed with the OS, isn't that better than one version for each app?
Managing several versions shouldn't be that hard (have a look at https://nixos.org/nix/\).
It would mean for Apple (and others who'd distribute compiled frameworks) to maintain several code bases of the same framework given that they would need to maintain backward compatibility and hence wouldn't be able to use new language features, etc. It's IMHO not that much about the technical constraint of having multiple binaries within the framework bundle as much as maintaining the code in a way that would compile under all Swift versions you'd like to support.
It would mean for Apple (and others who'd distribute compiled frameworks) to maintain several code bases of the same framework given that they would need to maintain backward compatibility and hence wouldn't be able to use new language features, etc. It's IMHO not that much about the technical constraint of having multiple binaries within the framework bundle as much as maintaining the code in a way that would compile under all Swift versions you'd like to support.
Rather than Apple have to commit in perpetuity to ship all relevant versions of the frameworks, one could imagine more of an app-thinning/install-time optimization: “thinned” versions of apps would be built and signed without the shared system frameworks, but with dependency information recorded. At install-time, the app would be installed, and the working set of required shared frameworks on the device would be updated with any needed dependent frameworks. Thus only the set of frameworks required by installed apps would be present on device.
This would require more app store, install-time, and perhaps dynamic linking, infrastructure, but would seem to solve the problem in a way that wouldn’t require ongoing development resources be applied to old versions.
i.e., you’re really just automatically factoring out frameworks that are common/redundant across apps in order to make install(ed) payloads smaller.
···
On Jan 27, 2017, at 9:21 AM, James Berry <jberry@rogueorbit.com> wrote:
If I understand things correctly, as long as the declarations for any new API features which depend on new ABI features are wrapped in "if swift(>= _relevant_version_goes_here_) … #endif” statements, the system frameworks could be one codebase that the runtime vender compiles to multiple targets, right? Because any code that relied on Swift 5’s shiny new, non-backwards compatible, generics feature (or whatever) simply wouldn’t exist in the runtime/stdlib that Swift 3 binaries are looking for? Or is this one of those things that works better in theory than it does in practice? Specifically, I don’t know if code that’s correct when compiled for Swift 3’s ABI is always still correct when it’s compiled for Swift 4/5/etc’s ABI. If it is, it seems like it’d make the task much easier... For each subsequent version of the ABI, we'd only need to test the parts of the stdlib that depend on the new ABI, since the parts that could be compiled for earlier ABIs would’ve already been tested when that version of the runtime/stdlib was compiled. At least, if it does actually work that way.
I very much agree that only having to deal with one runtime and one version of the system frameworks is clearly the ideal, but I also think it’s important to have an accurate understanding of what it would really cost a vendor/organization to commit to supporting multiple versions.
- Dave Sweeris
···
On Jan 27, 2017, at 8:59 AM, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 27, 2017, at 5:43 PM, Tino Heth <2th@gmx.de <mailto:2th@gmx.de>> wrote:
- runtime libraries for Swift 4
- all system frameworks will need to contain two variants - one compatible with Swift 4 and one with Swift 5. This is IMHO absolutely unmaintainable in the long run. For how long would you need to keep several versions of the framework around? What happens when Swift 6 comes along with another breaking changes? Would each system framework have 3 versions embedded?
That's right. If the OS frameworks use Swift then either (1) you have to clone the framework stack for each Swift version, or (2) you have only one copy of the frameworks but frameworks and apps can't share their Swift objects or publish Swift API.
The framework structure that Apple inherited from NeXT supports framework versioning, but *no frameworks use it*. It doesn't scale.
sure, it's preferable to have a single version that works with all apps — but if it's technically possible to have one clone installed with the OS, isn't that better than one version for each app?
Managing several versions shouldn't be that hard (have a look at https://nixos.org/nix/\).
It would mean for Apple (and others who'd distribute compiled frameworks) to maintain several code bases of the same framework given that they would need to maintain backward compatibility and hence wouldn't be able to use new language features, etc. It's IMHO not that much about the technical constraint of having multiple binaries within the framework bundle as much as maintaining the code in a way that would compile under all Swift versions you'd like to support.
Abstract classes do not require anything special in terms of runtime support. The ABI for an abstract class is basically the same as the ABI for a class except that you don't need to emit anything that would only be used for creating an instance of that class as the most-derived class. We'd probably want to reserve a bit in the metadata to say "this class is abstract" just for reflection purposes, but even that can be done retroactively.
John.
···
On Jan 27, 2017, at 11:09 AM, David Scrève via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 27, 2017, at 2:57 AM, Charlie Monroe via swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
That's right. If the OS frameworks use Swift then either (1) you have to clone the framework stack for each Swift version, or (2) you have only one copy of the frameworks but frameworks and apps can't share their Swift objects or publish Swift API.
The framework structure that Apple inherited from NeXT supports framework versioning, but *no frameworks use it*. It doesn't scale.
(NeXT used framework versioning a few times, back when the entire OS only had a handful of frameworks. Today's AppKit and Foundation are version C. libSystem is version B. That's about it.)
I completely agree with ABI stability goal…I only have a fear regarding some postponed evolutions requests especially Abstract Classes. Would it be still possible ?