Ownership y funciones: mover, devolver y el porqué del borrowing

Las funciones no tienen reglas de ownership propias: obedecen las mismas tres que ya conoces. Un parámetro es otra variable que toma posesión; pasar un argumento es una asignación disfrazada; devolver es mover hacia fuera. Al llevar el ownership a las llamadas descubrimos un problema práctico —cómo seguir usando un valor después de prestárselo a una función— cuya solución elegante, el borrowing, es el tema del nivel 9.

Pasar por valor mueve

Cuando pasas un valor no-Copy a una función, lo mueves dentro de ella. El parámetro se convierte en el nuevo dueño, y tu variable original deja de ser válida. Al terminar la función, el parámetro sale de su scope y el valor se libera allí:

fn main() {
    let s = String::from("dato");
    consume(s);          // s se MUEVE a la función
    // println!("{s}");  // ERROR E0382: s ya no es válido aquí
}

fn consume(texto: String) {
    println!("{texto}");
} // `texto` sale de scope: el buffer se libera aquí

Con un tipo Copy la historia cambia: el argumento se copia y tu original sigue vivo. Por eso puedes pasar un i32 a mil funciones sin perderlo, pero un String desaparece de tu poder en la primera llamada por valor.

fn duplica(n: i32) -> i32 { n * 2 }

fn main() {
    let x = 10;
    let y = duplica(x);    // x se COPIA al pasarse: sigue válido
    println!("{x} y {y}"); // 10 y 20, ambos usables
}

flowchart LR
dueno[main posee s] -->|pasa por valor| fn[consume toma la posesion]
fn -->|fin de la funcion| drop[s se libera dentro de consume]

Devolver transfiere la propiedad

El movimiento también fluye hacia fuera. Una función puede crear un valor y cederte la propiedad devolviéndolo. El dueño pasa a ser la variable que recibe el resultado:

fn produce() -> String {
    let s = String::from("nuevo"); // creado dentro de la función
    s                              // se mueve HACIA FUERA, al llamador
}

fn main() {
    let mio = produce(); // `mio` es ahora el dueño del String
    println!("{mio}");
}

En la práctica, el compilador construye el valor directamente en el hueco del llamador y elide el move, así que devolver por valor no cuesta una copia del buffer. La propiedad viaja; los bytes del heap, no.

El patrón incómodo: devolver para seguir usando

Aquí choca el ownership con la ergonomía. Si una función necesita leer un valor por valor, se lo tienes que ceder, y si luego lo quieres de vuelta, la función se ve obligada a devolvértelo. Con datos y resultados, esto degenera en tuplas:

fn longitud(s: String) -> (String, usize) {
    let n = s.len();
    (s, n)          // hay que devolver `s` o el llamador la pierde
}

fn main() {
    let s = String::from("hola");
    let (s, n) = longitud(s); // recuperamos `s` junto al resultado
    println!("{s} mide {n}");
}

Funciona, pero es horrible: cada función que solo quiere mirar un dato tendría que ir devolviéndolo, y las firmas se llenan de valores de ida y vuelta que no aportan nada. Escala fatal. Tiene que haber una forma de dejar que una función acceda a un valor sin arrebatarte la propiedad.

La salida: prestar en vez de ceder

La hay, y se llama borrowing. En lugar de mover el valor, le pasas una referencia con &: la función obtiene acceso temporal para leer, pero tú sigues siendo el dueño. No hay move, así que tu variable sigue válida después de la llamada.

fn longitud(s: &String) -> usize { // toma prestado, no posee
    s.len()
}

fn main() {
    let s = String::from("hola");
    let n = longitud(&s);      // le PRESTAMOS s, no se la damos
    println!("{s} mide {n}");  // seguimos siendo dueños: s sigue viva
}

Y si la función necesita modificar el valor sin apropiárselo, se presta de forma mutable con &mut:

fn agranda(s: &mut String) {
    s.push_str(" y más");   // modifica en el sitio, sin poseer
}

fn main() {
    let mut s = String::from("texto");
    agranda(&mut s);        // préstamo mutable temporal
    println!("{s}");        // seguimos siendo dueños: "texto y más"
}

El nivel 9 formaliza las dos formas de préstamo —compartido (&, muchos lectores a la vez) y exclusivo (&mut, un único escritor)— y las reglas que impiden que choquen. Aquí basta con ver que existen y que disuelven el patrón incómodo de la sección anterior: nadie tiene que devolver un valor solo para que su dueño lo recupere.

Con esto cierras el mapa del ownership básico: mover cede la propiedad, devolver la entrega, prestar la comparte sin soltarla. Todo lo que viene después —lifetimes, slices, smart pointers— son refinamientos sobre estas tres operaciones: quién posee un dato, quién puede tocarlo y durante cuánto tiempo.