The Evolution of “safe” and “unsafe” in Swift
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.
[…]
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.
If you’ve ever encountered the dreadful
UnsafeMutableRawBufferPointeror one of its friends and ran to stackoverflow… then this post is for you!
Previously:
- Swift Concurrency Interoperability With Objective-C
- Swift Concurrency Roadmap
- Unsafe Swift: Using Pointers and Interacting With C
- Why Safe C Is Sometimes Unsafe Swift
