We have now shown that once isolation is strictly controlled that even time-based asynchrony can be tested in a synchronous fashion with 100% deterministic results.

And we only showed this for immediate clocks, but a similar thing can be shown with test clocks, which are a kind of clock that suspend forever when they sleep and only un-suspend when someone from the outside tells them that some amount of time has passed. Test clocks are great for when you want to test truly test every aspect of how time flows through your features, and helps you wiggle into every little nook and cranny of your code, but there is just a tiny bit of work that needs to be done in Swift before this is possible. We need nonisolated(nonsending) versions of both withUnsafeContinuation and withTaskCancellationHandler. Once that is possible test clocks will be able to squash all unnecessary suspension points and give us the ability to fully test the flow of time without sprinkling yields all throughout our code.

Let’s move on to the next demo to show off just how amazing isolation, non-copyable types and non-escaping types are. While working on this series we worked on a little demo to get a better understanding of how everything works. That demo provides a safe interface to a popular C library that enforces the rules of the library statically so that the compiler can help prevent us from interacting with the library incorrectly.

The C library in question here is indeed SQLite, something we have talked about a ton on recent episodes, and some might say too much. We promise we are not opening that topic back up right now. What we are discussing here really has nothing to do with SQLite and has everything to do with interacting with global mutable state in a safe, ergonomic and performant manner.

We are not going to be spending a ton of time explaining how SQLite works. We’ve already done that in past episodes. Instead we are going to be using it as a really interesting example to show how in shockingly few lines of code we can enforce correctness when it comes to interacting with a tricky and easy-to-get-wrong C interface.

I will now demo what we were able to accomplish with Swift in just a few days of playing around with Swift’s tools, and then later in this series we will show what it takes to build these tools.