The Safety of Unsafe Swift
summary
Swift forbids direct memory access by default but exposes controlled unsafe APIs so code can be fast without undefined behavior. The standard library supplies hashing for many types, yet custom hashing mistakes turn O(1) lookups into linear or quadratic attacks; a naive XOR of identical fields collapses to zero and causes collisions. Better implementations consume bytes and spit out a final value using over a half a dozen pointer types, avoiding heap allocation is expensive by keeping unsafe code isolated in small, well-tested APIs.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 0:32Unsafe behavior
- 1:27Pointer types
- 2:35Hash value example
- 2:52Hash to 0
- 3:14Fake Hash
- 3:35Heap Allocation
- 4:06Client Hashing
- 4:20Protocol Extensions
- 4:39Conclusion
related talks
34mSo You Think You Know Swift?
24mMemory-safe interoperation between safe and unsafe languages
20mSwift WTF: Weirdness, traps, and fixes
31mSwift Secrets: Unlocking the Power of 'Any' and 'Some'
28mUsability Meets Performance in Swift
01h 00mThe Mysterious Swift Performance
44mSo You Think You Know Swift
58mSwift: safety, ergonomics, productivity and legacy preservation