Ownership e Borrowing in Rust: la guida completa per padroneggiare la gestione della memoria

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.

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.

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.

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.

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.

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.

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.

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.

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++.

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.

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.

// 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.

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.

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, 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 permette di acquisire fluidità prima dei colloqui tecnici