Language downgrade tool for source libraries

I think making #if more flexible is a must as this scenario could happen again.

It seems clear that at some point something changed in Swift’s direction as there seems to have been a clear desire not to have a very powerful pre-processor syntax the way C has for example and it was something the language design kept in mind.

Getting back on topic, I think it is likely to be needed in future scenarios so delaying improvements to #if is not ideal, especially as we see a need for it now and we cannot exclude we will be able to restrict swift not to need it. This goes also for being able to pass pre-processor flags down to SPM packages (they are free not to use them, but it can allow app devs and library authors another delegate of freedom in their contracts).

2 Likes

I think there's a gem of an idea here that can be made to work. I think the important difference is that we can't have the downgrade tool only run at release time: as you note, we need continuous testing. But that's ok: we can run it in our CI jobs for older releases.

You're right to indicate that this can really only help with syntactic sugar for now, but that doesn't entirely have to be true: there are lots of special cases that can be worked around by using shims or other tools. So I definitely think there's something here.

2 Likes

This seems like a tooling solution to an internal Apple political problem, namely the refusal to support newer versions of Swift on older versions of macOS. If macOS was supported as well as Linux, I don't think we'd need this at all. I'd be perfectly happy moving Alamofire to require the latest Swift version on a regular basis if users could actually upgrade to it without needing to upgrade their OS or buy new hardware.

Even if that weren't the case, what would prevent this tooling from falling into the same trap as the Swift conversion system already built into the compiler? That is, a tool that can only be used in very rare cases where support was manually added, not when it's most useful. Given the dominant opinion that it's not appropriate to require users to run the upgrader to support certain features, and that the conversion system is not a solution to source evolution, why would this tool be more appropriate?

In any event, personally, I don't think this is a good idea.

10 Likes

Now, what would make this a better idea would be full integration into the Swift development experience. That is, the ability to set my current and deployment Swift versions and have the compiler generate the appropriate package definitions and source files during build. Integration with registries would also be great so that users of particular Swift versions would only pull down the code necessary to build for their Swift version, not every version.

Additionally, being able to do this for all backward source compatibility would be huge. I mean things like Swift 5.3's (or 5.2's?) keypath to function equivalence, or the possible if let x feature currently being reviewed. One of the reasons Alamofire dropped Swift < 5.3 rather quickly is because I wanted to adopt the keypath feature rather than switching between syntax forms on my various projects.

1 Like

that, and the guard let rebindings