Polonius lets Rust skip an allocation the borrow checker used to demand

A cache hit should not require manufacturing a key that the cache already owns. Yet a familiar stable-Rust workaround does exactly that:

map.entry(key.to_owned()).or_insert(0)

HashMap::entry is an excellent combined lookup-and-insertion API, but it takes an owned key. When the caller has only &str and the map stores String, key.to_owned() runs before Rust can discover that the entry already exists. The HashMap documentation confirms both halves of this contrast: borrowed references can query owned keys, while entry accepts key: K.

The obvious alternative has long annoyed the stable borrow checker:

fn direct<'a>(
    map: &'a mut HashMap<String, usize>,
    key: &str,
) -> &'a mut usize {
    match map.get_mut(key) {
        Some(value) => value,
        None => {
            map.insert(key.to_owned(), 0);
            map.get_mut(key).unwrap()
        }
    }
}

A human reading this can see that the mutable reference returned by get_mut exists only in the Some branch. The None branch has no such reference, so inserting there is safe. The current stable checker nevertheless treats the returned borrow as lasting across the function and rejects the later mutable operations.

Polonius Alpha follows the control flow more precisely. The Rust team describes this as flow-sensitive checking of lifetime outlives relationships: a borrow alive along one branch need not be considered alive along another. This is not a relaxation of Rust’s aliasing rules; it is a more precise proof that this program already obeys them.

A small probe with a visible receipt

This complete program counts every conversion from a borrowed &str into an owned String:

use std::collections::HashMap;
use std::sync::atomic::{AtomicUsize, Ordering};

static OWNED_KEYS: AtomicUsize = AtomicUsize::new(0);

fn owned(key: &str) -> String {
    OWNED_KEYS.fetch_add(1, Ordering::Relaxed);
    key.to_owned()
}

fn via_entry<'a>(
    map: &'a mut HashMap<String, usize>,
    key: &str,
) -> &'a mut usize {
    map.entry(owned(key)).or_insert(0)
}

fn direct<'a>(
    map: &'a mut HashMap<String, usize>,
    key: &str,
) -> &'a mut usize {
    match map.get_mut(key) {
        Some(value) => value,
        None => {
            map.insert(owned(key), 0);
            map.get_mut(key).unwrap()
        }
    }
}

fn reset() {
    OWNED_KEYS.store(0, Ordering::Relaxed);
}

fn count() -> usize {
    OWNED_KEYS.load(Ordering::Relaxed)
}

fn main() {
    let mut entry_map = HashMap::from([(String::from("apple"), 7)]);
    reset();
    *via_entry(&mut entry_map, "apple") += 1;
    println!("Entry hit constructed {} owned key", count());

    let mut direct_map = HashMap::from([(String::from("apple"), 7)]);
    reset();
    *direct(&mut direct_map, "apple") += 1;
    println!("Polonius hit constructed {} owned keys", count());

    reset();
    *direct(&mut direct_map, "pear") += 1;
    println!("Polonius miss constructed {} owned key", count());
}

The official Rust Playground can compile the same source with stable or nightly, making the comparison reproducible without a local toolchain. In the recorded probe on September 19, 2026, stable Rust 1.98.1 rejected direct with two E0499 errors. Nightly Rust 1.100.0-nightly from September 18 compiled it and printed:

Entry hit constructed 1 owned key
Polonius hit constructed 0 owned keys
Polonius miss constructed 1 owned key

That output is an observation from this particular program. The broader inference is that borrowed-key caches with frequent hits can avoid repeated key construction—and, for String, usually an allocation—without switching APIs or performing a second unconditional conversion. The size of any real speedup depends on hit rate, key cost, allocator behavior, and surrounding work; the counter demonstrates the eliminated operation, not a universal benchmark result.

What changed, and what did not

As of the cited Rust announcement, Polonius Alpha is enabled by default only on nightly while the team looks for performance regressions, soundness problems, and diagnostic issues. The team reports generally acceptable performance across heavily downloaded crates, but also says its worst observed specialized cases were two to three times slower. Alpha also does not accept every program handled by the older experimental Polonius formulation.

So this is presently a useful preview, not permission to assume the code works on stable. For a stable library, Entry remains the straightforward supported choice, and its eager owned-key construction may be entirely negligible. For a nightly experiment or a hot cache path already known to spend time building keys, however, the direct version is finally worth measuring. The pleasing part is not merely that more code compiles: the compiler can now recognize the branch structure programmers meant all along.