Pitch: Automatic inclusion of new standard library features when supporting older versions of Swift

abistability
(George) #1

Now that Swift is ABI stable, I'm worried the community will run into the same problem iOS developers have had to face for years. Namely, when Apple would release a fancy new feature at WWDC, we would need to wait for some time before using it because most of the time (and per Apple's own recommendation) we were targeting the last two releases of iOS and the previous release did not contain said fancy new feature!

Let me illustrate with a specific example:
Ordered collection diffing is landing in 5.1. We write some code using this new feature, but when we compile targeting an older version of iOS, which provides its own older version of Swift, we get an errorr that 'difference(from:)' is only available on OS X 9999 or newer (that OS X 9999 thing is what the current toolchain displays, and in reality it would likely say something like Swift 5.1)

Swift has one advantage here, in that it is open source, so the enterprising developer can go ahead and copy that method from the standard library and encase it in a #if swift(<5.1), but this feels a little heavyweight and may cause some unexpected behavior if the behavior diverges between Swift versions or if they make a mistake like grabbing the file at the wrong commit version.

It would be great if there was a mechanism to do this automatically. For instance a @embeddableSince(5.0) attribute which would, when targeting Swift 5.0, simply embed the functionality in the resulting binary.

Is there an existing mechanism would better address this issue? Am I missing something that makes this not a problem? Any feedback is greatly appreciated!

4 Likes
(Thomas Krajacic) #2

I think this is similar to the question I asked a while ago on how to "polyfill" features for previous releases?

I think it would be incredibly useful especially since we have ABI stability.

3 Likes
(Jordan Rose) #3

It's also extra tricky with types (and conformances, for that matter), because types (and conformances) have much more of a run-time presence than functions and computed properties. We'd have to make sure that the version that ships with the Apple OS takes precedent when running on a new enough OS, since that's the one that will get bug fixes and stuff. I don't think it's impossible but it is tricky; like the previous post it needs implementation design (not necessarily from Apple, though!) and isn't something we can just put through as a proposal right away.

(Adrian Zubarev) #4

I would love to have a slice of stdlib in my app bundle that contains everything that the OS on which the app is running does not have in its glued stdlib. That would mean that Swift developers which stuck to some older OS’s will be limited by only some runtime related features, but would still be able to fully utilize the evolving stdlib.

I personally would also want to see a sliced runtime extension bundled with my app, so I can always use the latest and greatest language and stdlib features in my app like pre ABI stability. ABI stability might be great for Apple as they will avoid waste of space for apps in their data centers and on user devices, but for many of us developers it‘s feels like just like a kick in the butt (to be clear this is just critics so please take no offense by this).

I know there are technical boundaries for the things I wish, but it does not hurt anyone if I speak my issue with the ABI stability out loud. :slight_smile:

1 Like
(George) #5

Yeah, I worried that the complexity of this would outweigh the benefits. After all, Apple could have at any point implemented this feature for iOS in Xcode but they chose not to. While not a proof, that is something of a signal that the emergent complexity isn’t worth it.

(Adrian Zubarev) #6

I‘ll doubt it, but my fingers are crossed :crossed_fingers: for some WWDC surprises.

1 Like