{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihakdlajpv5na7egwxt26joidi24ffhdskmcmbdztmdtcv2frde2i",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mlzvzsnlsph2"
  },
  "path": "/t/reducing-raw-pointer-footguns-preventing-reference-aliasing-violations-at-compile-time/24301?page=2#post_34",
  "publishedAt": "2026-05-17T06:18:17.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "Rust compiler performance survey 2025 results | Rust Blog",
    "Clippy Lints"
  ],
  "textContent": "fuji-184:\n\n> So right now, there is still no warning for it. A ready to use compile time check is better than a compile time check that requires a complex Clippy setup, because realistically, most general users not using that setup anyway, which means the end result for the majority of users is effectively the same\n\nUnless the respondents to this survey are _extremely_ unrepresentative, the vast majority of Rust users do in fact run `cargo clippy` (and roughly a quarter, including myself, do so after every code change): Rust compiler performance survey 2025 results | Rust Blog\n\nRunning that two-word `cargo clippy` command currently has 67 deny-by-default lints (Clippy Lints) and a little over 400 warn-by-default lints. Incredibly useful, even without a more thorough setup.\n\nfuji-184:\n\n> So I do not really understand what you mean by “limiting productivity”.\n\nI was referring to a language where \"as many errors as possible are checked at compile time\" -- namely, where _all_ errors are checked at compile time -- not just your suggestion. Imagine a language which lets you use all the powers you could in C or `unsafe` Rust but requires you to provide a rigorous computer-readable mathematical proof that your program is sound. That's an extreme which would be difficult to work with. Presumably, it could still be worth its cost in rare cases, but not usually.\n\nfuji-184:\n\n> Even having two `&mut` references to the same memory is checked at compile time, so why not also check for two pointer and reference pointing to the same memory, especially if it is already possible to detect it?\n\nI think detecting it in Miri would be quite feasible. I'm not sure how hard it would be to check at compile time, I've never tried to implement a lint.",
  "title": "Reducing Raw Pointer Footguns: Preventing Reference Aliasing Violations at Compile Time"
}