Short version for the impatient: most borrow checker errors are the compiler asking one question, “who is still holding this?”, and you can answer it faster than you think once you stop reading the error from the top.<\/p>\n
I came to Rust from PHP and JavaScript, where nobody asks who owns anything. You pass an array around, mutate it in three places, and find out on Friday which place was wrong. So the first few weeks of Rust felt like arguing with a very polite auditor. The error messages are good, genuinely better than most compilers manage. My problem was that I read them as complaints instead of as questions, and my fix for every complaint was the same: add That works, and it’s also how you end up with a Rust program that is slower than the PHP it replaced. Here are the four errors I see most, what each one is really asking, and the restructure that beats cloning.<\/p>\n The Rust Book chapter on references and borrowing<\/a> states it in two lines. At any given time you can have either one mutable reference or any number of immutable references to a value. And references must always be valid.<\/p>\n That’s the whole borrow checker. Everything else is the compiler working out, for each reference in your function, the stretch of code between where it’s created and where it’s last used. If a mutable and an immutable stretch overlap on the same value, you get an error. The word “last used” matters. Since non-lexical lifetimes landed, a borrow ends at its final use and not at the closing brace, which is why some code that looks guilty compiles fine.<\/p>\n Hold on to that idea of a stretch of code. Every error below is two stretches overlapping.<\/p>\n The most common one for newcomers is E0382<\/a>, use of a moved value. The ownership chapter<\/a> says each value has one owner, and passing a My old reflex was Taking Next up is E0502<\/a>: you cannot borrow something as mutable because it’s already borrowed as immutable. The classic version is holding a reference into a vector and then pushing to it.<\/p>\n Coming from other languages this looks harmless, and in Rust the danger is concrete. The two stretches in this example are easy to see: If you needed the reference, finish using it before you mutate, which means moving the E0499<\/a> is the one that taught me the most, because the fix isn’t obvious until you know one detail about how the checker sees structs. Take a struct with two separate collections and a helper method for each.<\/p>\n Look at what the signature of Inside a single function, though, the checker does track fields separately. That gives you the fix:<\/p>\n Same behaviour, no clone, no The last one is E0106<\/a>, and it has the scariest reputation. It shows up when a function returns a reference and the compiler can’t tell which input the reference comes from.<\/p>\n The function could return either argument, so the caller needs to know how long the result stays valid. The fix is a small annotation that says both inputs and the output share one lifetime:<\/p>\n The One more thing I’ll say, since people ask: if you find yourself writing lifetime annotations on a struct in your second week, stop and return an owned Here’s the routine I follow when the compiler complains, and it took me embarrassingly long to settle on it. I skip the top line and go to the labelled spans in the middle of the message. Rust marks where the first borrow starts, where the conflicting use happens, and where the first borrow is still needed. Those three marks are your two overlapping stretches. Then I ask which one I can shorten.<\/p>\n Usually I can shorten the first by finishing with it earlier, or copy a small value out instead of holding a reference, or change a function signature from owned to borrowed. Only after that do I consider a clone, and when I do, I leave a comment saying why. I also wrote about who checks the lifetime in Rust versus C++<\/a>, and the short reason to put up with all this is that the check exists so you aren’t doing it by eye at 2am.<\/p>\n I’m still learning the harder territory here, namely async code holding references across Open one Rust project of yours, or a small throwaway, and run The four Rust borrow checker errors I hit most, what each one is really asking, and the restructure that beats .clone(). Before and after code for every case.<\/p>\n","protected":false},"author":2,"featured_media":825,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"The four Rust borrow checker errors I hit most, what each one is really asking, and the restructure that beats .clone(). Before and after code for every case.","rank_math_focus_keyword":"rust borrow checker","rank_math_canonical_url":"","rank_math_robots":"","footnotes":""},"categories":[142],"tags":[145,630,146,50,64],"class_list":["post-826","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-rust","tag-borrow-checker","tag-lifetimes","tag-ownership","tag-programming","tag-rust"],"_links":{"self":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/826","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/comments?post=826"}],"version-history":[{"count":0,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/826\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media\/825"}],"wp:attachment":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media?parent=826"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/categories?post=826"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/tags?post=826"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}.clone()<\/code> until it went away.<\/p>\nThe rule the compiler is enforcing<\/h2>\n
Moved value: you handed it away<\/h2>\n
Vec<\/code> or a String<\/code> into a function by value transfers that ownership. The caller can’t use it afterwards.<\/p>\nfn shout_all(v: Vec<String>) -> Vec<String> {\n v.into_iter().map(|s| s.to_uppercase()).collect()\n}\n\nfn main() {\n let names = vec![String::from("ada"), String::from("linus")];\n let loud = shout_all(names);\n println!("{} names, first is {}", names.len(), loud[0]);\n \/\/ error[E0382]: borrow of moved value: `names`\n}\n<\/code><\/pre>\nshout_all(names.clone())<\/code>. It compiles. It also copies every string in the vector just so a function can read them. The question the compiler is really asking is whether shout_all<\/code> needs to own the data, and here it plainly doesn’t. It only reads.<\/p>\nfn shout_all(v: &[String]) -> Vec<String> {\n v.iter().map(|s| s.to_uppercase()).collect()\n}\n\nfn main() {\n let names = vec![String::from("ada"), String::from("linus")];\n let loud = shout_all(&names);\n println!("{} names, first is {}", names.len(), loud[0]);\n}\n<\/code><\/pre>\n&[String]<\/code> instead of Vec<String><\/code> also makes the function accept arrays and slices, so it’s the better signature regardless. If a function only reads, borrow. If it keeps the value or changes it for good, take ownership. Cloning is the third option, and it should be a decision rather than a reflex.<\/p>\nMutating while someone is reading<\/h2>\n
fn main() {\n let mut scores = vec![10, 20, 30];\n let top = &scores[0];\n scores.push(40);\n println!("top score: {top}");\n \/\/ error[E0502]: cannot borrow `scores` as mutable\n \/\/ because it is also borrowed as immutable\n}\n<\/code><\/pre>\npush<\/code> may reallocate the vector’s buffer, and then top<\/code> points at memory that has been freed. In C++ that’s a bug you find in production. Here it’s a compile error, which I now consider a fair trade even on the days it irritates me.<\/p>\ntop<\/code> is alive from line 3 to line 5, and push<\/code> sits in the middle. There are two honest fixes, and the right one depends on what you wanted. If you only needed the value, copy it out, since integers are Copy<\/code>:<\/p>\nlet top = scores[0];\nscores.push(40);\nprintln!("top score: {top}");\n<\/code><\/pre>\nprintln!<\/code> above the push<\/code>. What you should not do is reach for RefCell<\/code> or unsafe<\/code> to silence the check. RefCell<\/code> moves the same conflict from compile time to a runtime panic, which is a worse place to find it.<\/p>\nTwo mutable borrows through a method<\/h2>\n
struct Inventory {\n items: Vec<String>,\n log: Vec<String>,\n}\n\nimpl Inventory {\n fn items_mut(&mut self) -> &mut Vec<String> {\n &mut self.items\n }\n fn note(&mut self, msg: &str) {\n self.log.push(msg.to_string());\n }\n}\n\nfn main() {\n let mut inv = Inventory { items: vec![], log: vec![] };\n let items = inv.items_mut();\n inv.note("adding a lamp");\n items.push("lamp".to_string());\n \/\/ error[E0499]: cannot borrow `inv` as mutable more than once\n}\n<\/code><\/pre>\nitems_mut<\/code> promises: a mutable borrow of self<\/code>, the whole struct, for as long as the returned reference lives. The checker doesn’t peek inside the method body to see that only items<\/code> is touched. So note<\/code> collides with it, even though log<\/code> and items<\/code> have nothing to do with each other.<\/p>\nfn main() {\n let mut inv = Inventory { items: vec![], log: vec![] };\n let items = &mut inv.items;\n inv.log.push("adding a lamp".to_string());\n items.push("lamp".to_string());\n}\n<\/code><\/pre>\nRefCell<\/code>. The cost is that you’re reaching into fields from outside the struct, which some people dislike on design grounds. If that bothers you, the other fix is to split the struct into two smaller ones that each own one collection, and I think that’s usually where the design wanted to go anyway. If you want another example of ownership details shaping an API, I wrote up Vec::into_parts and the Box leak habit I had to drop<\/a>. In my experience an awkward API is often pointing at an awkward ownership story.<\/p>\nMissing lifetime specifier<\/h2>\n
fn longest(a: &str, b: &str) -> &str {\n if a.len() > b.len() { a } else { b }\n}\n\/\/ error[E0106]: missing lifetime specifier\n<\/code><\/pre>\nfn longest<'a>(a: &'a str, b: &'a str) -> &'a str {\n if a.len() > b.len() { a } else { b }\n}\n<\/code><\/pre>\n'a<\/code> doesn’t change how long anything lives. It’s a label that tells the checker “the result is valid for as long as both of these are”. The lifetime syntax chapter<\/a> walks through exactly this example, and I’d read it twice. I did not understand it the first time, and I’m still not sure I’d explain it well to a colleague without a whiteboard.<\/p>\nString<\/code> instead. Lifetimes in structs are a real tool. They are also a lot of ceremony for code that wasn’t hot to begin with.<\/p>\nHow I read the errors now<\/h2>\n
.await<\/code> points, and trait objects with borrowed data. Those errors look different and I don’t trust my instincts on them yet.<\/p>\nTry this week<\/h2>\n
grep -rn \"\\.clone()\" src\/<\/code>. For each hit, ask whether the function receiving it only reads. If it does, change the parameter to a borrow and delete the clone. Do five of them and run cargo build<\/code> after each, so the compiler tells you which ones were hiding a real ownership question. If you want help moving a PHP or Node service toward Rust without a rewrite, my portfolio<\/a> shows the kind of migration work I take on.<\/p>\n","protected":false},"excerpt":{"rendered":"