{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifqvbuxz3oa56l5tnq5xhdjjaesyzruaa4cmwlka7jj4kd7qstn5m",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mluuqffv7gf2"
  },
  "path": "/t/reducing-raw-pointer-footguns-preventing-reference-aliasing-violations-at-compile-time/24301#post_2",
  "publishedAt": "2026-05-15T06:39:04.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "Aren't `.mutable_reference()` and `.immutable_reference()` just piggy-backing off of Rust's normal `&` and `&mut` semantics, just applied to `guard` instead of `a`? It doesn't look like your compile-time checks add anything beyond `&` and `&mut`.\n\nAlso.... just looking around, a lot of the methods you wrote are just `mem::transmute` in a \"safe\" trench coat. (That is, they're unsound. Size and align are **far** from the only aspects of a type that matter.)\n\nTaking a step back and looking at the big picture, _even if you solve those problems_ , your desired goal (compile-time errors for aliasing violations) is **impossible** in general. There is simply some information that you cannot know until runtime, and tools like Miri exist to test for UB, including aliasing violations, at runtime.\n\nThe purpose of raw pointers is to be used in places where compile-time checks are overly restrictive.\n\nGranted, with a sufficiently complicated type system and sufficiently verbose annotations, you probably _could_ encode a lot more invariants into the type system for compile-time checks. But speaking from experience as somebody who does _very complicated_ manipulation of lifetimes, `unsafe` traits, higher-kinded trait bounds, etc... encoding too many invariants into the type system becomes a massive hassle that brushes against the edges of what's possible in Rust, and I'd imagine that most people aren't willing to deal with all that, all in exchange for... moving relatively-simple `unsafe` code into an overengineered system which likely uses plenty of `unsafe` internally? Probably a bit anticlimactic, even if it _can be_ useful to remove `unsafe` from downstream code.\n\nIMO, the best way to reduce the footguns associated with raw pointers is to better teach people Rust's \"operational semantics\". Piecing together a good mental model of how `unsafe` Rust works is currently... difficult. You have to do a lot of searching for information yourself, on random docs and forums and conversations.",
  "title": "Reducing Raw Pointer Footguns: Preventing Reference Aliasing Violations at Compile Time"
}