{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibrisuxapivmki74adb2tjjrz2q5w6q6qbpxkobeyp2f2w356chke",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mluuqateyyt2"
  },
  "path": "/t/reducing-raw-pointer-footguns-preventing-reference-aliasing-violations-at-compile-time/24301#post_3",
  "publishedAt": "2026-05-15T08:01:15.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "Yeahhh that's why we can guarantee a compile time error whenever there's a reference aliasing violation, because we're leveraging the checks present in safe Rust. The mechanism is similar to `RefCell::borrow_mut`, with the difference being that it's purely at compile time. In safe Rust, references receive this compile time check, whereas references originating from unsafe raw pointers do not, we're required to follow aliasing rules manually, which is prone to human error since there are no checks. My motivation for creating this is that many people say unsafe Rust is difficult because of the aliasing rules. By using a new intermediate struct here called `AliasingGuard` which can be think of as having the same utility as the struct `RefCell::borrow_mut` but at compile time, we can bridge the gap between unsafe raw pointers and safe references to gain the compile time checks found in safe Rust. Since following aliasing rules in unsafe Rust manually is essentially trying to replicate safe Rust's reference rules by hand, this bridge removes that manual burden because the automatic aliasing rule checks in safe Rust are already at work. The `&` and `&mut` checkers can not be disabled even if the things are only known at runtime, instead they are encoded in the type system, so this is guaranteed\n\nThe aliasing rules are mandatory for all references, including those converted from raw pointers. Violating this is UB, so it's not an optional choice, but a requirement\n\n  * If there is an active immutable reference to A, we can not create a mutable reference to A\n  * If there is an active mutable reference to A, we can not create another mutable reference to A\n\n\n\nThe purpose here is to prevent the incorrect conversion of a raw pointer into a reference that violates the reference aliasing rule. It isn't for checking aliasing rules for raw pointers, because raw pointers themselves don't have aliasing rules, references do. We can not avoid the restrictiveness of references even if we create them using raw pointers, but following the rules manually, so it is like coding C and C++ where thing relies on human dicipline\n\nSo, simply by using an intermediate struct and methods that utilize `&` and `&mut` rules, we can prevent reference aliasing rule violations, for references generated from raw pointers, at compile time\n\nFor other methods, we just need to add whatever checks are missing, this is optional but good to create. It's not a reason to stop. The goal of this discussion is to identify what’s missing, determine if those gaps can be filled, and keep exploring until we hit a wall, at which point we can pause and see if there's a better approach\n\nWhat is most clear is the compile time error method for the aliasing rules mentioned above. Rust's goal is to move as many errors as possible to compile time, that’s the whole reason we have the borrow checker, to prevent mistakes at compile time. One aspect of this now is gradually giving unsafe Rust better ways to prevent mistakes, specifically regarding raw pointer to reference conversions that violate aliasing rules in this case. It's like having a way to prevent data races at compile time so we don't need Miri. If something can be checked at compile time, it's better than relying on Miri, because Miri needs to trigger every execution path to achieve 100% coverage, which is time consuming for large codebases. If there's a massive code update, we'd also need a massive update to the tests to ensure they run and maintain 100% coverage. With compile time checks, none of that is necessary. This is why Rust's advantage as a language with extensive compile time checks is so significant",
  "title": "Reducing Raw Pointer Footguns: Preventing Reference Aliasing Violations at Compile Time"
}