`unsafe` does not turn off the borrow checker

The five abilities

Inside an unsafe block, and only there, you may:

1. Dereference a raw pointer (*const T, *mut T)
2. Call an unsafe function or method — including every extern "C" FFI call
3. Access or modify a mutable static
4. Implement an unsafe trait (Send, Sync, and others)
5. Access the fields of a union

That is the complete list. Nothing about borrows, moves, lifetimes or types changes.

fn main() {
    let mut v = vec![1, 2, 3];

    unsafe {
        let first = &v[0];
        v.push(4);
        println!("{first}");
    }
}

error[E0502]: cannot borrow `v` as mutable because it is also borrowed as immutable

let ptr: *const i32 = &v[0];
v.push(4);
unsafe { println!("{}", *ptr); }   // compiles — and is genuine UB

Undefined behaviour

The stakes are higher than “might crash”. UB means the compiler is permitted to assume the situation never happens, and to optimise on that basis. A program with UB has no defined meaning at all — it may work for a year and then break when you upgrade the compiler or add an unrelated function.

The main sources in Rust:

• Dereferencing a dangling or unaligned pointer
• Producing two &mut to the same data (aliasing violation), even transiently
• Data races
• Reading uninitialised memory
• Producing an invalid value for a type — a bool that is not 0 or 1, an enum with an out-of-range discriminant, a &T that is null
• Breaking an invariant a safe API relies on (a String containing invalid UTF-8)

That fifth one is worth pausing on. unsafe code must uphold every type’s validity invariant, including the ones the compiler enforces elsewhere. A String with invalid UTF-8 constructed via from_utf8_unchecked is UB, and the crash will happen somewhere else entirely.

The point: safe abstractions

Here is the reframing that makes unsafe make sense.

Vec is implemented with raw pointers, manual allocation, and ptr::copy_nonoverlapping. String too. Rc, Arc, Mutex, HashMap, slice::split_at_mut — all unsafe inside.

And all of them are impossible to misuse from outside. That is the design:

Confine unsafe behind an API whose safe surface cannot be used incorrectly.

So “this crate contains unsafe” is not a red flag by itself. Any crate doing low-level work, FFI, or high-performance data structures will contain some. The questions worth asking are better ones:

• Is the unsafe confined to a small, reviewed module?
• Does each block have a // SAFETY: comment giving the argument?
• Does the crate run under Miri in CI?
• Is the safe API genuinely unmisusable, or does it merely document requirements?

// SAFETY: `idx < self.len` was checked on the line above, and `self.ptr`
// is valid for `self.len` elements by the type invariant.
unsafe { &*self.ptr.add(idx) }

That comment is the proof obligation, written down. Its absence in a review is a legitimate and specific thing to raise — far more useful than “why is there unsafe here?”

Edition 2024 changes

Two changes worth knowing, since they show up in newer code and in migration discussions.

The body of an unsafe fn is no longer implicitly an unsafe block. You now write explicit unsafe {} blocks inside it. The reasoning is good: an unsafe fn declares “callers must uphold preconditions”, which is a different statement from “every line in here may do unsafe things”. Conflating them hid real bugs.

// Edition 2024
unsafe fn thing(p: *const u8) -> u8 {
    // SAFETY: caller guarantees p is valid and aligned
    unsafe { *p }
}

extern blocks must be marked unsafe extern, and some attributes are now unsafe(...) — for example #[unsafe(no_mangle)]. Both make the danger visible at the declaration rather than implicit.

Miri

cargo +nightly miri test runs your tests in an interpreter that detects UB — out-of-bounds access, use-after-free, alignment violations, aliasing violations that ordinary testing will never surface.

It is slow, it cannot run FFI, and it does not cover every case. It is still by some distance the most useful tool for validating unsafe code, and serious crates run it in CI.

As a tech lead, this is the practical takeaway: if you are evaluating a dependency that contains meaningful unsafe, checking whether it runs Miri in CI tells you more than reading the code will.

What you should now be able to say

• unsafe unlocks five abilities and disables nothing — the borrow checker still runs.
• UB is not “might crash” — it means the program has no defined meaning, and the compiler optimises on the assumption it cannot happen.
• The purpose of unsafe is to build safe abstractions. Vec and String are unsafe inside and unmisusable outside.
• // SAFETY: comments are the written proof obligation.
• Miri detects UB at run time; CI usage is a good dependency signal.
• Edition 2024 requires explicit unsafe blocks inside unsafe fn.

Next: 5.2 — The idiom catalogue.