Rust ownership en borrowing vormen het fundament van de geheugenveiligheidsgaranties van Rust. In tegenstelling tot talen met een garbage collector dwingt Rust strikte regels af tijdens het compileren via de borrow checker. Hiermee worden hele categorieën bugs -- null pointer dereferences, data races en use-after-free-fouten -- geëlimineerd zonder runtime-overhead. Elke waarde in Rust heeft precies één eigenaar. Wanneer de eigenaar buiten scope valt, wordt de waarde vrijgegeven. Ownership kan worden overgedragen (moved) of tijdelijk uitgeleend (borrowed). Deze drie regels vervangen garbage collection volledig. ## Hoe move-semantiek garbage collection vervangt De meeste programmeertalen laten meerdere variabelen verwijzen naar dezelfde heap-toegewezen data. Rust kiest voor een andere aanpak: het toewijzen van een heap-waarde aan een andere variabele *verplaatst* deze, waardoor de oorspronkelijke binding ongeldig wordt. De compiler dwingt dit af zonder enige runtime-kosten. ```rust // move_semantics.rs fn main() { let original = String::from("interview prep"); let moved = original; // ownership transfers here // println!("{}", original); // compile error: value moved println!("{}", moved); // works fine } ``` Dit voorkomt double-free-bugs. Het type `String` alloceert op de heap, dus Rust zorgt ervoor dat slechts één variabele die allocatie op enig moment bezit. Typen die uitsluitend op de stack leven, zoals `i32` of `bool`, implementeren de `Copy`-trait en worden gedupliceerd in plaats van verplaatst. ```rust // copy_vs_move.rs fn main() { let x: i32 = 42; let y = x; // copy, not move -- i32 is Copy println!("x = {}, y = {}", x, y); // both valid let s1 = String::from("hello"); let s2 = s1.clone(); // explicit deep copy println!("s1 = {}, s2 = {}", s1, s2); // both valid after clone } ``` Het verschil tussen `Copy` en `Clone` is relevant voor technische interviews: `Copy` is impliciet en goedkoop (bitsgewijs kopiëren), terwijl `Clone` expliciet is en kostbaar kan zijn (heap-allocatie). ## Borrowing met onveranderlijke referenties Overal ownership overdragen zou code onpraktisch maken. Rust borrowing lost dit op door toegang tot een waarde uit te lenen zonder het eigenaarschap over te dragen. Een onveranderlijke referentie (`&T`) biedt alleen-lezen-toegang, en meerdere onveranderlijke referenties kunnen naast elkaar bestaan. ```rust // immutable_borrowing.rs fn calculate_length(s: &String) -> usize { s.len() // read access through the reference } // s goes out of scope, but doesn't drop the String (not the owner) fn main() { let greeting = String::from("hello, Rust"); let len = calculate_length(&greeting); // borrow, don't move println!("'{}' has {} characters", greeting, len); // greeting still valid } ``` Het symbool `&` creëert een referentie die de waarde leent. De functiesignatuur `&String` geeft aan dat `calculate_length` leent zonder eigenaarschap over te nemen. Na terugkeer van de functie behoudt de aanroeper het volledige eigenaarschap. Op elk moment kan een waarde hebben: meerdere onveranderlijke referenties (`&T`), OF precies één veranderlijke referentie (`&mut T`). Nooit beide tegelijkertijd. Deze regel voorkomt data races tijdens het compileren. ## Veranderlijke referenties en de exclusiviteitsregel Veranderlijke referenties (`&mut T`) geven schrijftoegang, maar dwingen exclusiviteit af: er kan slechts één veranderlijke referentie naar een waarde bestaan in een gegeven scope. Dit voorkomt dat twee stukken code tegelijkertijd dezelfde data wijzigen. ```rust // mutable_borrowing.rs fn append_greeting(s: &mut String) { s.push_str(", welcome to Rust!"); // modify through mutable ref } fn main() { let mut message = String::from("Hello"); append_greeting(&mut message); println!("{}", message); // "Hello, welcome to Rust!" } ``` Het sleutelwoord `mut` verschijnt op drie plaatsen: de variabelebinding (`let mut`), het referentietype (`&mut`) en de functieparameter. Alle drie zijn vereist. Een poging om een tweede veranderlijke referentie in dezelfde scope te creëren veroorzaakt een compilatiefout. ```rust // exclusivity_rule.rs fn main() { let mut data = String::from("shared state"); let r1 = &mut data; // let r2 = &mut data; // compile error: second mutable borrow println!("{}", r1); // After r1's last usage, a new mutable borrow is allowed let r3 = &mut data; // this works -- non-lexical lifetimes r3.push_str(" updated"); println!("{}", r3); } ``` De Rust 2021-editie maakt gebruik van non-lexical lifetimes (NLL): een borrow eindigt op het laatste punt van gebruik, niet aan het einde van het scopeblok. Dit maakt de exclusiviteitsregel ergonomischer zonder de veiligheid op te offeren. ## Lifetimes: de compiler vertellen hoe lang referenties leven Lifetimes zijn de manier waarop Rust garandeert dat referenties nooit langer bestaan dan de data waarnaar ze verwijzen. In de meeste gevallen leidt de compiler lifetimes automatisch af via *lifetime-elisieregels*. Expliciete annotaties worden noodzakelijk wanneer meerdere referenties met elkaar interageren. ```rust // lifetime_annotation.rs fn longest<'a>(x: &'a str, y: &'a str) -> &'a str { if x.len() > y.len() { x } else { y } } fn main() { let result; let string1 = String::from("Rust ownership"); { let string2 = String::from("borrowing"); result = longest(string1.as_str(), string2.as_str()); println!("Longest: {}", result); } } ``` De `'a`-syntax is een lifetime-parameter -- het annoteert relaties die al bestaan. De functiesignatuur zegt: "de outputreferentie kan niet langer leven dan welke inputreferentie dan ook." De compiler gebruikt dit om dangling references te voorkomen. ## Struct-borrowing en lifetime-grenzen Structs die referenties bevatten moeten lifetime-parameters declareren. Dit zorgt ervoor dat de struct niet langer kan bestaan dan de data waarnaar deze verwijst -- een veelvoorkomende bron van dangling pointers in C/C++. ```rust // struct_lifetime.rs struct Excerpt<'a> { text: &'a str, } impl<'a> Excerpt<'a> { fn summary(&self) -> &str { let end = self.text.len().min(20); &self.text[..end] } } fn main() { let article = String::from("Rust ownership model eliminates memory bugs"); let excerpt = Excerpt { text: article.as_str(), }; println!("Summary: {}", excerpt.summary()); } ``` De lifetime `'a` in `Excerpt<'a>` koppelt de geldigheid van de struct aan de onderliggende string. Het vrijgeven van `article` vóór `excerpt` zou een compilatiefout veroorzaken. Vragen over dangling references komen regelmatig voor in [Rust-interviews](/technologies/rust/interview-questions/smart-pointers). Het antwoord is altijd: Rust voorkomt deze tijdens het compileren via lifetime-analyse. Geen runtime-controles, geen null pointers. ## Ownership-patronen in productie-Rust Productie-Rust-code steunt op een aantal terugkerende ownership-patronen. Het herkennen ervan versnelt zowel de ontwikkeling als de prestaties tijdens technische interviews. ```rust // ownership_patterns.rs // Pattern 1: Take ownership, return a new value fn process_and_return(mut input: String) -> String { input.push_str(" -- processed"); input } // Pattern 2: Borrow for read-only inspection fn contains_keyword(text: &str, keyword: &str) -> bool { text.to_lowercase().contains(&keyword.to_lowercase()) } // Pattern 3: Borrow mutably for in-place modification fn sanitize(input: &mut String) { *input = input.trim().to_string(); } fn main() { let raw = String::from("user input"); let processed = process_and_return(raw); let found = contains_keyword(&processed, "input"); println!("Contains 'input': {}", found); let mut padded = String::from(" spaces everywhere "); sanitize(&mut padded); println!("Sanitized: '{}'", padded); } ``` De keuze tussen deze patronen volgt een eenvoudige heuristiek: leen standaard onveranderlijk, leen veranderlijk wanneer wijziging nodig is, en draag ownership alleen over wanneer de aanroeper de waarde niet langer nodig heeft. Deze aanpak wordt uitgebreid behandeld in de [Rust-basisgids](/blog/rust/rust-basics-experienced-developers). ## Borrow-checker-fouten en hoe ze te verhelpen De borrow checker produceert specifieke foutcodes. Het begrijpen van de meest voorkomende codes transformeert frustrerende compilatiefouten in eenvoudige oplossingen. ```rust // common_fixes.rs fn main() { let mut scores = vec![90, 85, 78]; let first = scores[0]; scores.push(95); println!("First: {}, All: {:?}", first, scores); let name = String::from("Alice"); let greeting = format!("Hello, {}", name); println!("{} says {}", name, greeting); let outer; { let inner = String::from("temporary"); outer = inner; } println!("{}", outer); } ``` Elke fix volgt hetzelfde principe: herstructureer de code zodat borrows en ownership in lijn zijn met de regels van Rust. Vechten tegen de borrow checker wijst doorgaans op een ontwerpprobleem dat in andere talen tot bugs zou leiden. Voor meer geavanceerde patronen met [concurrency en borrowing](/technologies/rust/interview-questions/concurrency-basics) worden gedeelde ownership-typen zoals `Arc` en `Mutex` essentieel. ## Conclusie - Elke Rust-waarde heeft één eigenaar; ownership wordt overgedragen bij toewijzing (move-semantiek) tenzij het type `Copy` implementeert - Onveranderlijke referenties (`&T`) bieden gedeelde leestoegang; veranderlijke referenties (`&mut T`) dwingen exclusieve schrijftoegang af - De borrow checker voorkomt data races en dangling references tijdens het compileren zonder runtime-kosten - Lifetimes annoteren referentierelaties -- ze beschrijven bestaande beperkingen, geen nieuwe - Wanneer de borrow checker code afwijst, herstructureer dan de ownership-flow in plaats van naar `unsafe` te grijpen - Oefen deze patronen met de [Rust-interviewvragen](/blog/rust/rust-interview-questions) om vloeiendheid op te bouwen vóór technische interviews