Ethan Brierley, a senior engineer at TrueLayer and co-organiser of Rust London, presented at QCon London 2026 to reframe one of the language’s most misunderstood features. Rather than explaining lifetimes through the traditional lens of scopes and regions of code, Brierley built his entire talk around an alternative mental model drawn from Polonius, an experimental borrow checker that treats lifetimes as sets of loans.
The shift sounds subtle, but it changes how you reason about a surprising number of lifetime puzzles. In the standard model, a lifetime is the stretch of code during which a reference is valid. In the Polonius model, a lifetime instead tracks all the possible places a reference might have originated. Each origin is a “loan,” and loans carry terms that must not be violated while the reference is alive. Borrow checking then becomes a line-by-line exercise: figure out which loans are live at each point, and check whether anything on that line violates their terms.
Brierley walked through a classic borrow checker error, mutating a variable while a shared reference to it still exists, and showed how the loans perspective makes the rejection obvious. The variable Y borrows from X, creating a loan. Y is still live when X gets mutated on the next line. The loan’s terms are violated. Error found. He compared the two mental models to solving a maze: you can think about the pathways through it, or the walls. Both get you to the same answer, but focusing on the walls can unlock understanding that the pathway view doesn’t.
From there, he built upward through lifetime parameters, subtyping, and variance. The longest function, a staple of Rust teaching, served as his running example. If a function returns one of two string slices, the output lifetime must be the union of both input lifetimes. That union relationship implies a subset relationship, which is where Rust’s outlives syntax comes from. Brierley reframed ‘a: ‘out not as “A lives longer than out” but as “A is inside out, because it contains fewer loans.“
Variance got the most careful treatment. Brierley explained that shared references are covariant loans that can always be added to their lifetimes. Function pointer arguments are contravariant, he stated, meaning loans can be removed. But references behind mutable references are invariant, the loan set is locked. Brierley demonstrated why with a worked example that would compile into a use-after-free if mutable references weren’t invariant over their type parameter. He noted that when you see a struct with multiple lifetime parameters, it’s almost always because those lifetimes have different variance, and collapsing them into one would force invariance across the board.
The talk wrapped with higher-ranked lifetimes, using serde’s Deserialize trait as the motivating example. When you write a function that takes an owned String, creates a slice from it, and passes that slice to serde_json::from_str, the lifetime of that slice can’t be named in the function signature; it originates inside the function body. The solution is for<‘de>, which says the type must implement Deserialize for every possible lifetime. Brierley showed how serde’s DeserializeOwned trait is just sugar on top of that higher-ranked bound, cleaning up a signature that would otherwise frighten people away from the crate.
Asked during Q&A about the Rust compiler’s roadmap, Brierley explained that Polonius is still under active development and not yet the default borrow checker. But when it lands, it will accept programs that are currently rejected, despite being memory-safe, lending iterators being the canonical example. The goal is to expand the set of correct programs the compiler accepts, not to change the safety guarantees. A second audience member drew a parallel between lifetimes and sets of loans, and between types and sets of values. Brierley paused on that one, admitted he hadn’t considered it before, and speculated the relationship might actually run in the opposite direction.
