@preconcurrency utilization in swift defined – Donny Wals

If you allow strict concurrency checks to your current tasks, it’s doubtless that Xcode will current a great deal of warnings and/or errors while you compile your venture for the primary time. On this publish, I’d like to check out a particular type of error that pertains to code that you simply didn’t write.

The @preconcurrency declaration could be added to:

• features
• varieties
• protocols
• imports

Let’s check out all of those areas to completely perceive how @preconcurrency helps us allow strict concurrency checks even when we are able to’t replace all of our dependencies simply but.

@preconcurrency imports

To be particular, Xcode will generally provide a message that reads lots like this:

Add @preconcurrency to suppress Sendable-related warnings from module MyModule

This error tells us that we’re importing a module that doesn’t seem to utterly adhere to trendy concurrency guidelines simply but. Since this won’t be a module that you simply personal, Xcode gives you the flexibility to silence strict concurrency warnings and errors coming from this module.

You are able to do this by including @preconcurrency to your import assertion:

@preconcurrency import MyModule

By doing this, Xcode will know that any warnings associated to varieties coming from MyModule ought to be suppressed.

If MyModule will not be a module that you simply personal, it makes loads of sense to suppress warnings; you possibly can’t repair them anyway.

Observe that this received’t suppress warnings associated to code from MyModule that is Sendable or up-to-date with trendy concurrency. So in case you see warnings associated to concurrency on a module that you simply’ve marked with @preconurrency, you’ll need to repair these warnings as a result of they’re right.

Including @preconcurrency to varieties, features, and extra

Alternatively, you is perhaps engaged on a module that has adopted Swift Concurrency and also you’ve mounted your warnings. If that’s the case, you may need to add @preconcurrency to a few of your declarations to make sure that code that is determined by your module doesn’t break.

Adopting Swift Concurrency will imply that your module’s ABI adjustments and that some older code won’t be capable to use your modules if that older code doesn’t additionally undertake Swift Concurrency.

If that is the state of affairs you’re in, you might need up to date a few of your code from this:

public class CatalogViewModel {
  public personal(set) var books: [Book] = []

  public init() {}

  func loadBooks() {
    // load books
  }
}

To this:

@MainActor
public remaining class CatalogViewModel {
  public personal(set) var books: [Book] = []

  public init() {}

  public func loadBooks() {
    // load books
  }
}

When you have pre-concurrency code that makes use of this class, it would look a bit like this:

class TestClass {
  func run() {
    let obj = CatalogViewModel()
    obj.loadBooks()
  }
}

Sadly including @MainActor to our class within the module makes it in order that we are able to’t use our view mannequin except we dispatch to the principle actor ourselves. The compiler will present an error that appears a bit like this:

Name to principal actor-isolated initializer ‘init()’ in a synchronous nonisolated context.
Name to principal actor-isolated occasion technique ‘loadBooks()’ in a synchronous nonisolated context.

This tells us that to be able to work together with CatalogViewModel, we’ll must replace our venture to make use of the principle actor. It will usually snowball into increasingly code updates which makes the adjustments in our module severely breaking.

We will apply @preconcurrency to our view mannequin to permit code that hasn’t been up to date to work together with our view mannequin as if it was by no means principal actor annotated:

@preconcurrency @MainActor 
public remaining class CatalogViewModel {
  public personal(set) var books: [Book] = []

  public init() {}

  public func loadBooks() {
    // load books
  }
}

Observe that the above solely works for tasks that don’t allow strict concurrency checking

With the @preconcurrency annotation in place for our complete class, the compiler will strip the @MainActor annotation for tasks which have their concurrency checking set to minimal. In case you’re utilizing strict concurrency checks, the compiler will nonetheless emit errors for not utilizing CatalogViewModel with the principle actor.

In Abstract

With @preconcurrency, we are able to import outdated modules into new code and we are able to enable utilization of latest code in outdated tasks. It’s a good way to begin to incrementally undertake strict concurrency as the discharge of Swift 6 comes nearer and nearer.

Including @preconcurrency to your imports could be very helpful while you’re importing modules that haven’t but been up to date for strict concurrency.

Including @preconcurrency to declarations that you simply’ve annotated as @Sendable, @MainActor, or in any other case up to date in a manner that makes it not possible to make use of them in non-concurrent code could make loads of sense for library authors.