Apologies if I've missed something (I suppose I must have), but on Mojave, using the Xcode 11 Beta 2, I get this error when using opaque result types:
'some' return types are only available in macOS 10.15.0 or newer
I was just wondering what's going on here. Is this a temporary restriction, or is this only going to be available on Catalina? I wanted to try on Linux using the latest 5.1 to see if it works there, but I'm getting errors from the Swift install, which I see some others are working out elsewhere on the forums.
Is it fair to say that opaque result types will be available everywhere Swift 5.1 is available by the time 5.1 is released?
The Swift runtime is now a component of the OS on Apple platforms, and opaque types require runtime support that's only in the new Apple OSes currently in beta, so APIs that use them can only be available on those newer OSes. On Linux, you should always be able to install the newest Swift runtime alongside the compiler.
Will it be possible to get some compile time warning in case the deployment target includes an OS version with an incompatible Swift version in case the unsupported runtime features are used?
Yes, the Xcode 11 beta 2 compiler will give you an error if you try to use runtime features that require a newer OS without the necessary availability attributes.
If you write an app in any of those languages, you also require your users then download sizable runtime distributables, usually one for every individual app that uses a slightly different version of the language runtime. It is possible that opaque types and other new Swift features in the future could eventually be back-ported to older OSes, because the runtime does provide hooks for backward deploying, but the engineering work hasn't been done for that yet.
I'm adamantly certain the if you polled users, this is what they would prefer, rather than being locked out of using new apps because their aging hardware has been deemed unfit to run the newest OSes. Try explaining to a customer:
Now I know the primary issue here is Apple's macOS forced obsolesce practices. Users who didn't know about these patching tools would miss out on new OS features. That's crappy, but it's not the end of the world. But with this coupling of the Swift runtime to OS versions, now they can't use new versions of their existing apps, or even entire apps (that don't have an old version). That sucks way more, and we're at fault.
Regardless, I understand the benefits of being able to off-board the runtime. But If you look at ecosystems, like the ones I mentioned above, their runtimes are packaged independently of the OSes.
Admittedly, Java's updater is particularly annoyingly implemented (surprised modal dialogues out of nowhere, whyyyy), but the idea is still sound.
Most people understand your frustration. However, this is a decision that has come and gone, and was never ours as the community to make. Apple decided that it wanted to declare Swift's ABI as stable on Darwin, and as such ship the Swift runtime with the OS. There's not much point in discussing it now.
I don't want to dismiss your concerns. We know this is an inconvenience, and we try to accommodate it as best we can, within the constraints of available implementation approaches and engineer resources. Note that most other new Swift 5.1 features, including the property wrappers and function builders used by SwiftUI currently under review, are purely compile-time and have no added runtime compatibility. The desire for backward deployment was a key consideration in the design of those features.
The Objective-C runtime is similarly bundled with the operating system and cannot be shipped separately with apps, because some system frameworks are written in Objective-C and there is no way to run multiple instances of an Objective-C runtime in the same address space. Same with Swift.
Not all new language features require runtime support. For example property wrappers, default arguments for member-wise initializers and other 5.1 language features can be used in any OS supported by Swift.
That isn't as much of an issue, IMO, because ObjC didn't have such big changes.
There are plenty of new runtime features that we would eventually want, and we're forced to either not use them, or to lock people with older hardware out. That's an unfortunate dichotomy, and completely technically unnecessary. Some examples (which I'm fairly sure would need runtime modifications, but correct me if I'm wrong):
Writeable dynamic reflection
Continuations
Fixed-length arrays
First class concurrency (actor model, or whatever we come up with)
Imagine explaining to a developer in another ecosystem that you can't use Async/Await in your code because only the latest OS version has the runtime to support it. You would be laughed at.
A lot of other ecosystems have the same problem at some level. With JS in the browser for example, usually the big holdout for new features is having to support the lowest common denominator of browser (which is usually certain browsers vended by Microsoft). Now JS can get around some things via polyfilling, but for core language features, sometimes there is no alternative.
And a lot of server-side stuff has arbitrary limits placed on them by cloud providers. AWS for example is pretty slow with keeping up with Node/Postgres/etc. So devs/ops are forced to either stick with what AWS offers out-of-the-box, or build and maintain custom images (which a lot of companies won't do for logistical as well as security reasons).
Even languages like Java still require users to download and install new JVM versions. And a lot of companies I've worked for refuse to upgrade things until the next LTS, so we're waiting regardless.
My earlier post was flagged, but I don't see a way to appeal. This was almost currently because I used the phrase "African war lords".
It's an inconvenient truth, but we have to contend with the fact that actions have consequences. The more artificial limitations we impose on old devices, the faster they're thrown out and replaced with new ones. The niobium and tantalum that goes into the high density capacitors of our beloved devices is commonly sourced from Coltan mines in the Democratic Republic of Congo.
There's literally a slave trade in Africa, with warlords and cartels competing for the rare Earth metal market. Google "Coltan mine" and observe one of our great moral failings. If you find that offensive, good, because it is. It's a massive source of human suffering and strife, and we're funding it. We bear responsibility for this.
There are already some efforts to clean up (morally speaking) the supply chain, like Intel's "Conflict Free" initiative, but we should all do our part. Obviously it's quite unrealistic to make people stop using electronics, but the least we can do it not make it worse by artificially decreasing the longevity of devices.
@Joe_Groff Is there a way to force the compiler to use a runtime that's embedded in a toolchain? We'd like to do so for the Swift for TensorFlow toolchain because we need to use ElementaryFunctions, if not opaque result types in the short term, and we'd like to keep our APIs in sync between Linux and macOS.
One thing I didn't see mentioned: will there be a point release for Mojave that updates its Swift runtime, or would shipping a new runtime be much more involved than simply updating some bundled libraries with no compatibility concerns?
And as a follow up: will there be a general policy on this going forward, that older OSes won't get newer runtimes in point releases, or will it be a case-by-case thing that depends on how involved the changes are?
No. You might be able to compile the added APIs into the compatibility library, or similarly, a supplementary swiftTensorflow static library you link alongside the OS runtime. See https://github.com/apple/swift/pull/25473 as an example.