Swift opens review of Cell and Volatile interior mutability types

Swift Evolution has opened formal review of SE-0556, which would introduce Cell, ConstCell, and Volatile types for interior mutability and volatile memory access. The change targets patterns that today push developers toward classes, unsafe pointers, or C bridges when they need shared mutable state inside value types or hardware-facing loads and stores.

Cell would allow mutation through an otherwise immutable binding, a building block for reference counts, caches, and low-level concurrent structures. ConstCell would expose a readable aliasable location whose contents may still change under the reader. Volatile would encode access semantics for memory that can be observed or updated outside ordinary program control, such as memory-mapped I/O or values a signal handler may touch, without requiring full synchronization primitives.

Review manager Freddy Kellison-Linn opened the period through 23 October 2026 and published trial toolchains for macOS and Ubuntu Linux. Feedback on the Swift forums has treated the problem as real while pressing on design fit.

Douglas Gregor argued that Volatile is a memory access semantic, not a locking tool, and should live in the standard library so C volatile interoperability does not depend on importing Synchronization. He also preferred the name ReadOnlyCell over ConstCell, because the type is not constant in the Swift sense: other parties may still mutate the location. Joe Groff warned that making such cells Sendable could force volatile or atomic loads so the compiler cannot invent redundant reads that assume a stable value.

Other reviewers questioned whether Volatile assignment and bulk span updates should carry observable side effects, whether Cell's unsafe borrow API weakens the safety of its ordinary operations, and how Sendable interacts with races against concurrent C writers. Embedded Swift users welcomed Volatile for MMIO work without a separate package or C shim. A RefCell-style wrapper with runtime exclusivity checking remains an open future direction rather than part of the current proposal.