Skip to content

Instantly share code, notes, and snippets.


Exclusivity Enforcement in Swift 5

The Swift 5 release enables runtime checking of "Exclusive Access to Memory" by default in Release builds. Previously, these runtime checks were only enabled in Debug builds. In this post, I'll explain what this change means for Swift developers and why it is essential to Swift's strategy for safety and performance.



Analyzing dispatch performance

When it comes to resilient performance we need to prioritize future flexibility and ABI simplicity over perceived performance advantages. Being able to react to future performance issues that arise with specific apps is far more important than benchmarking. Time not spent implementing complex ABI mechanisms is time that will be spent optimizing more critical performance areas.

It's easy to say we should simply measure performance and let the data


SE-0184 Part 1: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

Here I've listed the changes from SE-0184 that have been reviewed by the core team and are no longer considered controversial. Let's call this SE-1084 Part 1. The diff below summarizes SE-1084 Part 1 vs. Swift 4. The core team requests have been incorporated, and are annotated as "Amended" comments. The amendments are minor and almost exclusively revise the original Swift 3 API rather than calling into question anything newly introduced by SE-0184. Consequently, there's no need for those to go back to swift-evolution. The remainder of SE-0184, part 2, will introduce changes to the slice API in conjunction with the buffer API, so does need to go back to swift-evolution as a new proposal.


SE-0184 Part 2 (recomend splitting into a follow-up proposal): Buffer Full vs. Partial Initialization.

Buffer Memory State

struct UnsafeMutableBufferPointer<Element> 
    func initialize<S : Sequence>(from: S) -> (S.Iterator, Index) where S.Element == Element

// Amended: Remove the `at` label on all buffer APIs. Only support full initialization/assignment/deinitialization.

SIL Opaque Values


A SIL type is either loadable or address-only. A loadable type is one whose object size and layout can be determined by the compiler and whose values are not "pinned" to a memory address. Types are most commonly address-only because their layout is opaque by abstraction. Generic type parameters are address-only because their concrete type not statically identified. Resilient types are