The evolution of “safe” and “unsafe” in the Swift programming language

There’s been a lot of motion in the last four months of the evolution of the Swift programming language that I’ve been wanting, waiting, and hoping for. The language maintainers are tackling concurrency as a first-class construct in the language. I’m following along with the language evolution proposals in the forums, and so far have mostly been able to keep up with the details – although I’m sure I’m missing a lot of the fine-grained implications. Reading the forum pitches where people are talking them through has been fascinating.

One of the interesting take-aways is that the terms “safe” and “unsafe”, or at least the specific implications of when they’re used in the swift language, are broadening what they cover with the upcoming changes. You could start to see it as early as last October when the Swift Concurrency Roadmap was published, but the wording wasn’t fully in place, more of just conceptual frameworks. The details of the broadening of the definition didn’t hit home for me until I caught up with the recent discussion on the pitch for task local values.

Prior to these language extensions, “safe” implied something pretty narrow and specific: memory safety. It started with some swift-language specific guarantees about variables being guaranteed to be initialized before use. There’s a Swift.org blog post from back in 2015 that calls this out, and far more detail in The Swift Programming Language book’s chapter on Memory Safety. There’s an even better explanation and detail in the presentation Unsafe Swift from WWDC 20. The heart of it being that the “safe” APIs have more preconditions and guarantees wrapped around them.

Across the recent pitches and proposals, some of the language terms that use safe are now being used to imply concurrency safety, somewhat independently of memory safety. The goal looks to be to provide APIs that have some guarantees about thread-safe access and updates. And along with the safe versions, there are some potential “unsafe” variants to use when you need the escape hatch and are willing to take on the thread safety guarantees yourself.

There is likely going to be some detail about what it means to be safe in the upcoming 3rd pitch for Structured Concurrency (both the task local values pitch and the 2nd structured concurrency pitch mention another round of updates and details for the structured concurrency proposal. As I’m writing this, it’s clear there’s still a lot of active and careful work going on there.