Il sistema di ownership e borrowing rappresenta il cuore delle garanzie di sicurezza della memoria offerte da Rust. A differenza dei linguaggi con garbage collector, Rust applica regole rigorose in fase di compilazione attraverso il borrow checker, eliminando intere categorie di bug -- dereferenziazione di puntatori nulli, data race e use-after-free -- senza alcun overhead a runtime. Ogni valore in Rust ha esattamente un proprietario. Quando il proprietario esce dallo scope, il valore viene rilasciato (drop). L'ownership si trasferisce (move) oppure si presta temporaneamente (borrow). Queste tre regole sostituiscono completamente il garbage collection. ## Come la Move Semantics sostituisce il Garbage Collection La maggior parte dei linguaggi consente a variabili multiple di puntare agli stessi dati allocati sullo heap. Rust adotta un approccio diverso: assegnare un valore heap a un'altra variabile lo *sposta*, invalidando il binding originale. Il compilatore garantisce questa regola a costo zero. ```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 } ``` Questo meccanismo previene i bug di tipo double-free. Il tipo `String` alloca sullo heap, quindi Rust assicura che solo una variabile possieda quella allocazione in ogni momento. I tipi che risiedono esclusivamente sullo stack, come `i32` o `bool`, implementano il trait `Copy` e vengono duplicati invece che spostati. ```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 } ``` La distinzione tra `Copy` e `Clone` risulta rilevante nei colloqui tecnici: `Copy` agisce in modo implicito ed economico (copia bit a bit), mentre `Clone` richiede una chiamata esplicita e potenzialmente costosa (allocazione sullo heap). ## Borrowing con riferimenti immutabili Trasferire l'ownership ovunque renderebbe il codice poco pratico. Il borrowing in Rust risolve questo problema prestando l'accesso a un valore senza trasferirne la proprietà. Un riferimento immutabile (`&T`) permette l'accesso in sola lettura, e riferimenti immutabili multipli possono coesistere senza conflitti. ```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 } ``` Il simbolo `&` crea un riferimento che prende in prestito il valore. La firma della funzione `&String` dichiara che `calculate_length` prende in prestito senza acquisire l'ownership. Al termine della funzione, il chiamante mantiene la piena proprietà del dato. In qualsiasi momento, un valore può avere: molti riferimenti immutabili (`&T`), OPPURE esattamente un riferimento mutabile (`&mut T`). Mai entrambi contemporaneamente. Questa regola previene i data race in fase di compilazione. ## Riferimenti mutabili e la regola di esclusività I riferimenti mutabili (`&mut T`) garantiscono l'accesso in scrittura ma impongono l'esclusività: in un dato scope può esistere un solo riferimento mutabile a un valore. Questo impedisce a due porzioni di codice di modificare gli stessi dati simultaneamente. ```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!" } ``` La parola chiave `mut` compare in tre posizioni: il binding della variabile (`let mut`), il tipo del riferimento (`&mut`) e il parametro della funzione. Tutte e tre sono obbligatorie. Il tentativo di creare un secondo riferimento mutabile nello stesso scope genera un errore di compilazione. ```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); } ``` A partire dall'edizione Rust 2021, il linguaggio utilizza i non-lexical lifetimes (NLL): un borrow termina nel punto del suo ultimo utilizzo, non alla fine del blocco di scope. Questa ottimizzazione rende la regola di esclusività più ergonomica senza sacrificare la sicurezza. ## Lifetimes: indicare al compilatore la durata dei riferimenti I lifetimes rappresentano il meccanismo con cui Rust garantisce che i riferimenti non sopravvivano ai dati a cui puntano. Nella maggior parte dei casi, il compilatore inferisce automaticamente i lifetimes attraverso le *regole di elisione*. Le annotazioni esplicite diventano necessarie quando riferimenti multipli interagiscono tra loro. ```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); } } ``` La sintassi `'a` definisce un parametro di lifetime, non un concetto nuovo: annota relazioni che esistono già nel codice. La firma della funzione dichiara che il riferimento restituito non può sopravvivere a nessuno dei riferimenti in ingresso. Il compilatore sfrutta questa informazione per prevenire i dangling reference. ## Borrowing nelle struct e limiti di lifetime Le struct che contengono riferimenti devono dichiarare parametri di lifetime. Questo assicura che la struct non possa sopravvivere ai dati a cui fa riferimento -- una fonte comune di puntatori pendenti 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()); } ``` Il lifetime `'a` in `Excerpt<'a>` lega la validità della struct alla stringa sottostante. Rilasciare `article` prima di `excerpt` genererebbe un errore di compilazione, impedendo qualsiasi accesso a memoria non valida. Le domande sui dangling reference compaiono regolarmente nei [colloqui su Rust](/technologies/rust/interview-questions/smart-pointers). La risposta corretta è sempre: Rust li previene in fase di compilazione attraverso l'analisi dei lifetimes. Nessun controllo a runtime, nessun puntatore nullo. ## Pattern di ownership nel codice Rust reale Il codice Rust in produzione si basa su alcuni pattern ricorrenti di ownership. Riconoscerli accelera sia lo sviluppo quotidiano sia la preparazione ai colloqui tecnici. ```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); } ``` La scelta tra questi pattern segue un'euristica semplice: prendere in prestito in modo immutabile per impostazione predefinita, utilizzare il borrowing mutabile quando serve una modifica, e trasferire l'ownership solo quando il chiamante non ha più bisogno del valore. Questo approccio viene approfondito nella [guida ai fondamentali di Rust](/blog/rust/rust-basics-experienced-developers). ## Errori del borrow checker e come risolverli Il borrow checker produce codici di errore specifici. Comprendere quelli più comuni trasforma errori di compilazione frustranti in correzioni immediate e prevedibili. ```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); } ``` Ogni correzione segue lo stesso principio: ristrutturare il codice affinché i borrow e l'ownership siano allineati alle regole di Rust. Lottare contro il borrow checker segnala in genere un problema di progettazione che causerebbe bug in altri linguaggi. Per pattern più avanzati che coinvolgono [concorrenza e borrowing](/technologies/rust/interview-questions/concurrency-basics), i tipi di ownership condivisa come `Arc` e `Mutex` diventano essenziali. ## Conclusione - Ogni valore in Rust ha un unico proprietario; l'ownership si trasferisce all'assegnazione (move semantics) a meno che il tipo non implementi `Copy` - I riferimenti immutabili (`&T`) consentono l'accesso condiviso in lettura; i riferimenti mutabili (`&mut T`) impongono l'accesso esclusivo in scrittura - Il borrow checker previene data race e dangling reference in fase di compilazione con zero costo a runtime - I lifetimes annotano le relazioni tra riferimenti -- descrivono vincoli esistenti, non ne creano di nuovi - Quando il borrow checker rifiuta del codice, la soluzione consiste nel ristrutturare il flusso di ownership piuttosto che ricorrere a `unsafe` - Esercitarsi con questi pattern attraverso le [domande di colloquio su Rust](/blog/rust/rust-interview-questions) permette di acquisire fluidità prima dei colloqui tecnici