That's fair enough, but it's also important to consider the costs today of trying to support both. It's your judgement to make, of course, but I was considering this recently for a library I'm working on, so I'd like to share some of the things I considered:
- Continuous integration. If the code isn't being tested, it isn't worth having it sit around, growing stale. AFAIK only travis offers CI for IBM Z-series (for FOSS projects only).
- What if something goes wrong? I've had this problem recently with Windows - if a CI run fails for some reason on this platform, how easily can you reproduce the environment to debug it locally? Trying to guess at fixes through a CI log is super-unproductive.
- Availability of Swift. There was a port for z/OS, but the latest version I could find is 5.0.2 (from all the way back in July 2019!). Even small language additions, like the ability to omit a "return" in single-expression functions, won't be available - not to mention concurrency and any future extensions. Why box yourself in with those constraints?
- Reliability of the Swift port. I remember that users of the z/OS port would post here quite frequently with issues caused by bugs which only appeared on that platform - in particular, enums were quite fragile, and could result in strange crashes (remember that Optional is also an enum, so it comes up a lot), there were issues with heavily optimised types like
String, etc - mostly resulting from endianness, as it happens. Even if somebody did port Swift to a BE machine, it's going to be some work.
Ultimately, I decided it wasn't worth it. Either you have a bunch of untested code lying around, or you limit yourself to a buggy version of 5.0.2. And for what? The ability to say my project supports some incredibly niche system that the compiler itself doesn't even support any more?
If there ever is such a system worth porting to, it would be much easier to just port the project at that time.