Borrow Checker  vs  NLL  vs  Polonius

The Big Picture

All three terms describe the same job — enforcing Rust's ownership and borrowing rules at compile time. The difference is how precisely each one tracks when borrows are alive.

1. The Original (Lexical) Borrow Checker Pre-2018

The original borrow checker determined the lifetime of a reference from the lexical scope (the curly-brace block) in which it was created. A borrow lived from the let binding until the closing } — even if the reference was never used again.

Rules (unchanged across all versions)

The Problem: False Positives

Because the lexical checker tied lifetimes to scopes, it rejected many programs that were actually safe:

ERROR (pre-2018)
fn main() {
    let mut data = vec![1, 2, 3];

    let first = &data[0];        // immutable borrow starts here
    println!("{}", first);       // last use of `first`

    data.push(4);               // ❌ ERROR: `data` still borrowed!
}                               //    borrow of `first` ends HERE at `}`

The immutable borrow first was done being used after println!, yet the compiler kept it alive until the end of the block. This forced developers to use ugly workarounds like extra { } blocks to artificially shorten scopes.

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

    {
        let first = &data[0];    // borrow scoped to inner block
        println!("{}", first);
    }                           // borrow ends here

    data.push(4);               // ✅ OK now
}

2. Non-Lexical Lifetimes (NLL) Rust 2018 — Current

NLL, stabilised in Rust 1.31 (December 2018), was the single biggest ergonomics win in Rust's history. Instead of tying borrows to scopes, the compiler builds a control-flow graph (CFG) and computes the liveness region for every borrow — the set of program points where the reference might still be used.

How NLL Works

The previous example now compiles without any workaround:

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

    let first = &data[0];        // immutable borrow starts
    println!("{}", first);       // last use → borrow ENDS here

    data.push(4);               // ✅ OK — no active borrow
}

Where NLL Still Struggles

NLL analyses borrows in a location-insensitive way for the origin (provenance) of references. It knows when a borrow is used but not always which specific data is borrowed through a given reference at each point. This leads to false rejections in conditional borrowing patterns:

ERROR (NLL)
fn get_or_insert(map: &mut HashMap<String, String>, key: &str) -> &String {
    if let Some(v) = map.get(key) {   // immutable borrow of `map`
        return v;                       // returning the borrow
    }

    // NLL thinks `map` might still be immutably borrowed here,
    // because the borrow *could* have flowed to the return value.

    map.insert(key.to_owned(), "default".into()); // ❌ mutable borrow
    map.get(key).unwrap()
}

The problem: NLL cannot see that the return v branch and the map.insert branch are mutually exclusive. If we reached insert, we didn't return, so the immutable borrow is dead — but NLL's analysis isn't precise enough to prove that.

3. Polonius Next-Gen — Nightly

Polonius is the next-generation borrow checker being developed to replace NLL's internal engine. Named after Shakespeare's character from Hamlet, it flips the analysis model on its head.

The Core Difference: Origins, Not Lifetimes

This origin-sensitive, flow-sensitive analysis means Polonius can reason about conditional branches precisely. The example that fails with NLL works under Polonius:

OK (Polonius)
fn get_or_insert(map: &mut HashMap<String, String>, key: &str) -> &String {
    if let Some(v) = map.get(key) {
        return v;                       // loan flows to return → branch exits
    }

    // Polonius knows: if we reach here, the loan from `map.get()`
    // did NOT flow to any live reference. It's dead.

    map.insert(key.to_owned(), "default".into()); // ✅ no conflict
    map.get(key).unwrap()
}

How Polonius Works (Simplified)

Polonius uses Datalog-style rules to compute three key relations over the CFG:

By intersecting "which loans are reachable" with "which loans are invalidated" at each point, Polonius achieves precise, flow-sensitive, origin-sensitive analysis.

Side-by-Side Comparison

Practical Patterns Affected

Pattern 1: Use-then-mutate

OK since NLL
let mut v = vec![1, 2, 3];
let last = v.last();           // immutable borrow
println!("{:?}", last);        // last use
v.push(4);                     // ✅ NLL ends the borrow above

Pattern 2: Conditional borrow & mutate

OK with Polonius
fn get_default<'a>(map: &'a mut HashMap<i32, String>, key: i32) -> &'a String {
    if let Some(val) = map.get(&key) {
        return val;               // borrow exits via return
    }
    map.insert(key, String::from("default"));
    &map[&key]
}

Pattern 3: Self-referential insert-or-update

Needs Polonius
fn update_or_insert(map: &mut HashMap<i32, Vec<i32>>, key: i32, val: i32) {
    if let Some(vec) = map.get_mut(&key) {
        vec.push(val);           // mutably borrow map → get inner vec
        return;
    }
    map.insert(key, vec![val]); // NLL may reject; Polonius accepts
}

Timeline

Try Polonius Today

You can experiment with Polonius on nightly Rust:

# Install nightly
rustup toolchain install nightly

# Compile with Polonius enabled
RUSTFLAGS="-Z polonius" cargo +nightly check

# Or set it in .cargo/config.toml
[build]
rustflags = ["-Z", "polonius"]

TL;DR