Please don't describe such rationales as disingenuous. There are legitimate technical reasons why experimental toolchains can work but a general solution would differ, without calling into question the good faith of the person giving the explanation.
The technology for toolchains relies on overriding the system libraries on macOS and simulators, but this technology does not work in the general context of all apps deployed to all devices. A different technology would be needed to shim in just the specific capabilities needed to support concurrency backward-deploying. It may be possible, but it is certainly far more complex than the toolchain solution, and there would be many edge cases to be thought through and coded around.
Can you give any more information about which parts of the concurrency design might be particularly difficult to back-deploy?
Say, if features such as async/await and actors were limited to an applicationās own code (and its bundled dependencies) and had no direct support from the SDK. Granted, the experience would be far from optimal, and I appreciate that the team is exploring ideas which may be much better than that, but perhaps a commitment to at least that basic level of support would allow people to invest more time using swift concurrency.
Alternatively, is there any timeline for when we should expect further details? Before iOS15 ships?
As was noted in the previous thread, concurrency is the biggest feature to go through evolution, and arguably the biggest change to happen to swift, period. Itās understandable that developers would like to start adopting it and proving feedback as soon as possible.
Apologies, no offense intended. Thanks for the clarification on the difference between toolchain support and system level support.
I really hope system level support can be provided at least for the current generation osās, if not even one prior. It will help the adoption of this technology enormously .
My old Macs have newer versions of the Java JDK and .Net runtimes than they do the Swift runtime. Isn't something seriously wrong here?
The cost of coupling the shipping something as fundamental as the language runtime with the OS version is totally brutal.
It is not right for me to be part of the force that accelerates the obsolescence of users' devices and turns them into e-waste, just because I wanted to use opaque return types, structured concurrency, or other such developer luxuries.
I have always wondered why Apple seems so against back-deploying features. Other platforms do it regularly.
It doesn't have to be a shim, either; at the very least it could just be backported as an entire update to older OSes, i.e. iOS 14.6.1 (if 14.6 were otherwise the last version of iOS before 15) and iOS 13.7.1, right? This is done all the time for security fixes, why not OS features?
Well, one can choose which direction to expend the engineering force vector - full thrust ahead, or add a series of retardation maneuvers.
I think we should respect the effort involved in backporting new features to old platforms.
As a hypothetical example, Iād rather see a full fledged swift 6 in a years time with full thrust ahead rather than in two years if core contributors would spend time backporting the concurrency features to old os versions and to handle the inevitable fallout of bugs / corner cases.
Personally I prefer full thrust ahead as far as possible, to move the state-of-the-art forward faster.
Backwards compatibility isnāt just a āretardation manoeuvreā; it is critical to ensuring that Swift developers can actually use the feature, which in turn means that the core team can get feedback about how well it suits its intended purpose or whether anything needs adjusting (e.g. I expect actor reentrancy to be a big topic. How well will developers adjust? Weāll have to see).
Engineering isnāt a profession where you dream up a grand plan, entirely perfect at conception, and then just go away and build it. You constantly have to measure and adjust to realities that might only emerge as you build.
Fair enough, you are right in the sense that there is a tradeoff to be made, but it is enough that "enough" Swift developers can use it to provide feedback too, so exactly where to draw the line is always a fine art. I just wanted to point out that back porting features isn't for free and that you will inevitably lose momentum to some degree while doing it - and that we should respect the tradeoff that needs to be made.
I am well aware that engineering isn't a profession where you dream up a grand plan which is perfect at conception and build it, thanks - the important thing is just to get enough valid feedback and draw the line somewhere. I don't think anyone would argue for back porting everything 5 releases back. Especially since there are statistics - if 85%+ of all devices already run the latest iOS release (14), it seems likely that the same adoption rate will happen for the next release.
(I too believe that the actor reentrancy will be very interesting to follow - it seems likely to cause some trouble for many FWIW)
Not having all the details on the effort involved makes it impossible to second-guess such choices, but given that there are still a lot of fundamentally big things still missing (like e.g. memory ownership), I hope the pendulum will be swinging more towards forward thrust at this point - definitely understand others may have different views of course.
First of all, I want to thank the team for such a great concurrency model!
It is also good to hear backwards compatibility is being explored/considered, and I just wanted to add my +1 request for it.
While undesirable, I do think it is OK for us to work around & deal with the lack of backwards compatibility of Apple frameworks. The community/devs can build wrappers, reimplement some things and provide fallbacks for most of those things. However, if the language becomes the problem, there is nothing we can do but wait several years, which is extremely sad, given how cool, useful & convenient the Swift concurrency is
Can I choose to bundle a newer Swift runtime with my apps going forward to be able to use new runtime features without requiring a new OS?
This will not be possible for a number of reasons: [...]
Is there anything that can be done to allow runtime support for new Swift features to be backward deployed to older OSes?
It may be possible for some kinds of runtime functionality to be backward deployed [...] The Core Team will consider the backward deployment implications of new proposals under review on a case-by-case basis going forward.
but they're not ruling this out as impossible, if that's what you want.
If you compile a project a particular toolchain, you gotta make sure there's a supported runtime installed on the target machine as well.
Edit:
But I digress, this thread isn't really about ABI stability. And they probably already received feedbacks that some places would like back-deploy.
First off, thank you a million to the Swift team for implementing this!
This would be invaluable for us to be able to use these features immediately with the new Swift version. Many companies cannot just drop the last OS version when the new iOS comes out.
So, I'd like to just add a +1 to backwards compatibility for async/await.
That's not going to work IMO as it requires the users to have updated, and the gating of the #available goes well beyond the version number and would have to be changed to be feature based.
The updates need to be shipped as a library/bodge with the app that 'polyfills' the features onto older runtimes. ISTR that early Swift did this with the whole runtime to get working on devices before it stabilised and got bound to the OS - seems like we need to go backwards a bit to move forwards.
Then we need to decouple Swift apps/versions from the system as well - making new Swift features bind to (and only to) the latest OS release in a specific year is not going to work for the language long term.
In order to decouple Swift from OS versions, we would have to give up on Swift OS APIs. Libraries like Combine and SwiftUI would have to be shipped with the apps instead of the OS. This isnāt impossible, but the implications go way beyond the Swift teamās sphere of influence.
In an ideal world, I think the Swift runtime (and updated versions of Apple Frameworks) could be updated on demand on Apple platforms, similar to how Rosetta works on Apple Silicon Macs. i.e. the first time a user tries to download an app from the App Store requiring Swift x.y, the OS could download it as required (and hot-swap the existing system-wide frameworks/runtimes). Not saying this is even feasible at all, just an idea :)
No, it isn't one-to-one with completion handlers. The key difference is that functions that take a completion handler typically return immediately and the completion handler is triggered later (though you can't assume that the completion handler isn't called before the function returns; in some cases, for instance if results are already available, for instance from a cache, it might be).
With an async function, it won't return until execution gets to a return statement, falls off the end of the function, or the function throws. Instead, when an async function does an await, the thread it's on is freed up to do other work (i.e. other async functions may resume execution, and on the main thread/actor, the application's main run loop will run so that the UI remains responsive).
