Friday, February 12, 2021 [Tweets] [Favorites]

The Evolution of “safe” and “unsafe” in Swift

Joseph Heck:

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.

Paulo Andrade:

If you’ve ever encountered the dreadful UnsafeMutableRawBufferPointer or one of its friends and ran to stackoverflow… then this post is for you!

Previously:

Comments

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment