SE-0340 partially closes a potentially risky situation in Swift’s concurrency model, by allowing us to mark types and functions as being unavailable in asynchronous contexts because using them in such a way could cause problems. Unless you’re using thread-local storage, locks, mutexes, or semaphores, it’s unlikely you’ll use this attribute yourself, but you might call code that uses it so it’s worth at least being aware it exists.
To mark something as being unavailable in async context, use @available with your normal selection of platforms, then add noasync to the end. For example, we might have a function that works on any platform, but might cause problems when called asynchronously, so we’d mark it like this:
@available(*, noasync)
func doRiskyWork() {
}We can then call that from a regular synchronous function as normal:
func synchronousCaller() {
doRiskyWork()
}However, Swift will issue an error if we attempted the same from an asynchronous function, so this code will not work:
func asynchronousCaller() async {
doRiskyWork()
}This protection is an improvement over the current situation, but should not be leaned on too heavily because it doesn’t stop us from nesting the call to our noasync function, like this:
func sneakyCaller() async {
synchronousCaller()
}That runs in an async context, but calls a synchronous function, which can in turn call the noasync function doRiskyWork().
So, noasync is an improvement, but you still need to be careful when using it. Fortunately, as the Swift Evolution proposal says, “the attribute is expected to be used for a fairly limited set of specialized use-cases” – there’s a good chance you might never come across code that uses it.
SPONSORED Still waiting on your CI build? Speed it up ~3x with Blaze - change one line, pay less, keep your existing GitHub workflows. First 25 HWS readers to use code HACKING at checkout get 50% off the first year. Try it now for free!
Sponsor Hacking with Swift and reach the world's largest Swift community!
Other changes in Swift 5.7…
- if let shorthand for unwrapping optionals
- Multi-statement closure type inference
- Clock, Instant, and Duration
- Regular expressions
- Type inference from default expressions
- Concurrency in top-level code
- Opaque parameter declarations
- Structural opaque result types
- Unlock existentials for all protocols
- Lightweight same-type requirements for primary associated types
- Constrained existential types
- Distributed actor isolation
- buildPartialBlock for result builders
- Implicitly opened existentials
Download all Swift 5.7 changes as a playground Link to Swift 5.7 changes
