Rust memory model debate could make seqlocks safer and clearer

Rust’s hottest memory-model thread on June 2 was not about a flashy new API or a rewrite of the borrow checker. It was about whether low-level code that already lives on the edge, especially seqlocks, can be described in a way that feels less like a hack and more like part of the language.

The discussion, “Include racy reads in Rust memory model with MaybeInvalid<T>,” sat on the Rust Internals front page with 48 replies and 1,574 views. It built on an earlier March 16 proposal that split a problem Rust has argued over for years: uninitialized memory is not the same thing as an invalid value. That earlier thread sketched a MaybeInvalid<T> type as a #[repr(transparent)] union with an invalid: () sentinel and a value: ManuallyDrop<T> field, plus companion methods on MaybeUninit such as written(), assume_written(), assume_written_ref(), assume_written_mut(), and freeze().

That distinction matters because it gives race-tolerant code a more precise story. In the thread’s framing, the racy step in a seqlock could be modeled as a relaxed-atomic read, which would move a pattern that today often feels like unsafe folklore into a more explicit semantic model. For systems programmers, that is the whole prize: code that handles narrow races without pretending those races do not exist.

The seqlock angle is not new. A 2022 rust-lang/unsafe-code-guidelines issue on seqlocks and load-release/store-acquire noted that the proposal would match how Linux actually implements seqlocks, then corrected that it was not identical and might require stronger fences than Linux uses. That tension sits right at the center of Rust’s safety story. The Rust language docs say unsafe Rust exists because the compiler cannot verify every memory-safety contract, and the Rust Reference makes clear that undefined behavior includes violations of Rust’s rules even inside unsafe code.

The broader debate has been running for a long time. Rust Internals was talking about uninitialized memory back in 2015, and a 2020 thread asked why even unused data must be valid. The new MaybeInvalid<T> framing does not settle that history, but it sharpens the stakes: if the language can finally distinguish a truly invalid value from mere uninitialized bytes, seqlocks and other race-tolerant primitives could become easier to explain, easier to audit, and harder to get subtly wrong.