Given the dustup that's happened around async/await and the new concurrency features, should the Swift evolution template be updated to make it more clear when proposed changes will require changes to the Swift runtime and consequently won't be able to be used on previous versions of Apple's operating systems?
21 Likes
Since the proposal template already has source compatibility, ABI stability, etc., I think it seems logical to address this too.
3 Likes
1 Like
Suppose that a proposal says "this needs work from Apple teams in other organizations to back-deploy". What does the community do from there?
My general concern about the wording here is that folks don't necessarily know what can back-deploy and what can't. If we're going to ask them to say something about the technical concerns for backward deployment, we need to give more illustrations about what is easy vs. hard to back-deploy. For example, some things are easy to back-deploy, like a feature that is sugar over existing language features or a new API that can be fully-inlined. Other things are hard to back-deploy, like if you introduce a new type, new protocol conformance, or you change the type system in a way that can be discovered by a dynamic cast (as?/as!/is).
Doug
7 Likes
That's fair. I admittedly don't fully understand what can and what can't.
Do you feel like adding those examples is sufficient?
Adding this to the template will likely increase the core team's workload, in that many folks may not know how to answer this section and some back-and-forth will be required to help educate or to verify the claims made. Granted, the same could probably be said about the ABI stability section, too. I don't want to add work to the core team and reviewers, but I also feel like calling this out up front will be a net win for the community.
It does not seem to me that what ships or not on Apple’s platforms is actionable for anyone outside of Apple, or within the remit of Swift Evolution. What do you envision to be the net win for the community?
4 Likes
The fact that async/await (most likely) will not be back-deployable was surprising and frustrating to a lot of people. Many had been counting on being able to use it right away. If this had been discussed earlier it would have helped. So I think we'd like to avoid having this happen with future pitches.
This isn't really any different than the sections on ABI stability or API resilience. Most developers who aren't experts on those aspects of Swift will have to wait for input from someone who is. Deployability would be pretty similar.
3 Likes
Perhaps a better way to frame this issue is "Runtime and Standard Library surface impact"? As @xwu notes, "backwards deployable" is (today) an Apple-specific concern over which the Swift project has no purview. But if a proposal indicates that it requires additional runtime entry points or standard library changes (which cannot be emitted into the client), that's a pretty strong signal that any Swift-in-the-OS platforms (currently, Apple platforms) would need additional, perhaps significant, work to support the feature in a backwards-compatible manner.
Also, given that Swift does support ABI-stable platforms, it seems independently valuable to me (apart from answering the "will users get to use this feature on older iOS versions?" question) for proposals to indicate the additional commitments their features are making on the system side of the ABI boundary—those are decisions that we can't easily "take back" later. The community should have an opportunity to weigh the relative permanence of those decisions against the value that the new feature provides.
3 Likes
See the discussion from SE-0263. Apple will back-deploy what they feel like back-deploying. Even if there aren’t really any major technical difficulties, they still might not do it. Trying to make that process less arbitrary seems unlikely to succeed.
It’s their platform, after all. They are allowed to be arbitrary, and they will be.
3 Likes
I don't think anyone is under the illusion that they can make vendors do anything. It's more about making this consideration visible in the proposal itself, rather than just something that might come up in pitch or review or might be mentioned in the acceptance post.
2 Likes
It isn’t relevant, though. Just because something may technically be able to be back-deployed, that doesn’t mean it will be. Saying that some proposal may be back-deployed is misleading, IMHO, and will only make people angry at Apple when they decide not to.
3 Likes
Of course it's relevant, it may influence the implementers or reviewers. If implementers can find an alternate implementation that can be more easily backward deployed, that's a huge benefit to the community. Reviews may have new ideas or alternate versions of a feature that are easier to deploy. But if it's not something that's considered until Apple cuts a build, there's no opportunity for improvement at all.
1 Like
+1 to what Jon has been saying. I think that there was a lot of fire and frustration and threads that needed to be locked or closed which caused bad feelings for people on both the creating and receiving ends of the spectrum. The launch of concurrency into Swift could have been mostly an exciting celebration of the incredible work the authors have put into helping swift grow into a more powerful and safe language, where the users knew what to expect and the authors contributions were valued for what they were.
In general, I think that people can cope better with news they don't like more easily when there is more time to process it before a big announcement. I would suspect that if this had been called out more explicitly in the proposal that the actual reveal of concurrency would have been met with more celebration and less anger as the stakes would feel lower, there wouldn't be an element of surprise, and the discussions of the implementation details and technical problems would have been more easily managed in the review threads.
If we can excuse a poor metaphor, it's similar feeling to when you spend a lot of time using a service, customizing something only fo find out at the very end that it's not free or that you need to link some other sort of account to continue.
1 Like
The Core Team discussed the issue, and their view aligns closely with the above: backward deployment is a vendor-specific issue, and not part of the evolution process. However, calling out the runtime impact of a proposal can help us understand concerns around back-deployment and also the overall impact of a feature on the language and runtime, which is valuable.
The global actors proposal under review has some interesting runtime impact, so I've sketched a short section to talk about its runtime impact as a sample: [SE-0316] Address feedback from the second review by DougGregor · Pull Request #1400 · apple/swift-evolution · GitHub
Doug
7 Likes
I don't really have a dog in this race, but as someone who is explicitly not working with Apple platforms and Swift I have little idea what "backwards deployable" means or why it should be important when considering improvements to a language that ideally should have relevance outside of Apple platforms.