The distinction between checked and unsafe continuations in Swift – Donny Wals

Once you’re writing a conversion layer to rework your callback based mostly code into code that helps async/await in Swift, you’ll usually end up utilizing continuations. A continuation is a closure you could name with the results of your asynchronous work. You’ve got the choice to move it the output of your work, an object that conforms to Error, or you may move it a Outcome.

On this submit, I received’t go in-depth on displaying you easy methods to convert your callback based mostly code to async/await (you may check with this submit if you happen to’re keen on studying extra). As an alternative, I’d like to clarify the distinction between a checked and unsafe continuation on this quick submit.

Should you’ve labored with continuations earlier than, you will have seen that there are 4 strategies that you should utilize to create a continuation:

• withCheckedThrowingContinuation
• withCheckedContinuation
• withUnsafeThrowingContinuation
• withUnsafeContinuation

The primary factor that ought to stand out right here is that you’ve the choice of making a “checked” continuation or an “unsafe” continuation. Your intestine would possibly inform you to all the time use the checked model as a result of the unsafe one sounds… effectively… unsafe.

To determine whether or not that is right, let’s check out what we get with a checked continuation first.

Understanding what a checked continuation does

A checked continuation in Swift is a continuation closure you could name with the end result of a conventional asynchronous operate that doesn’t but use async/await, usually one with a callback closure.

This would possibly look a bit as follows:

func validToken(_ completion: @escaping (Outcome<Token, Error>) -> Void) {
  // ultimately calls the completion closure
}

func validTokenFromCompletion() async throws -> Token {
    return attempt await withCheckedThrowingContinuation { continuation in
        validToken { end in
            continuation.resume(with: end result)
        }
    }
}

The code above is a quite simple instance of bridging the standard validToken technique into the async/await world with a continuation.

There are a few guidelines for utilizing a continuation that you just want to bear in mind:

• You need to solely name the continuation’s resume as soon as. No extra, no much less. Calling the resume operate twice is a developer error and may result in undefined conduct.
• You’re accountable for retaining the continuation and calling resume on it to proceed your code. Not resuming your continuation implies that withCheckedThrowingContinuation won’t ever throw an error or return a price. In different phrases, your code can be await-ing ceaselessly.

Should you fail to do both of the 2 factors above, that’s a developer mistake and you must repair that. Fortunately, a checked continuation performs some checks to make sure that:

• You solely name resume as soon as
• The continuation handed to you is retained in your closure

If both of those checks fail, your app will crash with a descriptive error message to inform you what’s unsuitable.

In fact, there’s some overhead in performing these checks (though this overhead isn’t huge). To eliminate this overhead, we are able to make use of an unsafe continuation.

Is it vital that you just eliminate this overhead? No, in by far probably the most conditions I extremely doubt that the overhead of checked continuations is noticeable in your apps. That stated, if you happen to do discover a purpose to eliminate your checked continuation in favor of an unsafe one, it’s vital that you just perceive what an unsafe continuation does precisely.

Understanding what an unsafe continuation does

Briefly, an unsafe continuation works in the very same means as a checked one, with the identical guidelines, besides it doesn’t verify that you just adhere to the principles. Because of this errors is not going to be caught early, and also you received’t get a transparent description of what’s unsuitable in your crash log.

As an alternative, an unsafe closure simply runs and it’d crash or carry out different undefined conduct whenever you break the principles.

That’s actually all there’s to it for an unsafe continuation, it doesn’t add any performance, it merely removes all correctness checks {that a} checked continuation does.

Selecting between a checked and an unsafe continuation

The Swift group recommends that we all the time make use of checked continuations throughout improvement, at the least till we’ve verified the correctness of our implementation. As soon as we all know our code is right and our checked continuation doesn’t throw up any warnings at runtime, it’s secure (sufficient) to change to an unsafe continuation if you happen to’d like.

Personally, I want to make use of checked continuations even after I know my implementation is right. This enables me to proceed engaged on my code, and to make modifications, with out having to recollect to change backwards and forwards between checked and unsafe continuations.

In fact, there’s some overhead concerned with checked continuations and if you happen to really feel such as you would possibly profit from utilizing an unsafe continuation, you must all the time profile this primary and be sure that this change is definitely offering you with a efficiency profit. Making your code much less secure based mostly on assumptions is rarely an incredible concept. Personally, I’ve but to discover a purpose to favor an unsafe continuation over a checked one.