Just found out about `@available(SwiftStdlib 5.5, *)`

I wasn't fully sure how the async feature will be shipped and if it will be backwards deployed like for example Result type was. However now that I found this new versioning gate I think the answer to that question is a "no". Nevertheless I would still appreciate if someone from the core team would explicitly confirm or deny that.

Since async feature is internally driven by the Task family types, and all of that code is gated by @available(SwiftStdlib 5.5, *) I assume that non of that code will be available for applications to use with older deployment targets other than for application running on OSs that ship with sodlib 5.5 or newer?

I also assume that we can and should write code such as this snippet here:

if #available(SwiftStdlib 5.5, *) {
  // async code
} else {
  // do it the old school way
}
7 Likes

I was thinking about that yesterday but came to the conclusion that it will need a new OS (on apple platforms). AFAIK all the async stuff needs changes on the runtime, and since apple platforms have swift embedded I doubt we can ship apps that use async in older OSs.

The use of an availability macro will make it easier to update those
versions to the marketing versions when they are announced. Plus
internal branches can redefine only the macro for customized
availability.

Guess the macro will become @available(..., iOS 15, ...) later. 🥲

1 Like

backwards compatibility would be great, now it's awful

1 Like

Yeah, we need backward support like AndroidX (Support library) at least for the Swift language.

If we need to drop old versions to use async/await, this would really hurt the future of this language.

2 Likes

An iOS requirement higher than 12 or 13 would be a big fat bummer for the adoption of the concurrency movement. I sincerely hope that whoever decides this chooses wisely.

4 Likes

I sincerely doubt there is any malice behind that decision. I imagine it's either "it can't be done for older OSes" or "the cost of making it work on older OSes is too great". Recall that collection diffing and Identifiable are simiarly locked to iOS 13 and newer.

2 Likes

I understand that for devices such as SwiftUI or Combine which are not merely compiler things, but deeply intermingled with OS features. I would not understand this for concurrency. Not at all.

1 Like

After trying out the Xcode 13 beta, it seems functions marked with the async and await keywords compile without constraining the availability to the latest version of the targeted OS. However, actually invoking the very same mechanism with for instance runDetached (which makes use of Task), I get a compilation error that describes said features are exclusively available for the latest OS versions.

I would also love to hear if structured concurrency is meant only for the latest OS versions, and if that is the case, if back porting would possible via a compatibility library. In the WWDC videos I haven't seen any explicit marketing of structured concurrency and async/await as features pertaining exclusively to the latest operating system versions.

Please enlighten me if I'm wrong about any of the above mentioned :slight_smile:

1 Like

I was just made aware the discussion about this subject takes place here: Will Swift Concurrency deploy back to older OSs?

1 Like
Terms of Service

Privacy Policy

Cookie Policy