String frente a str: el dueño y la vista

El primer desconcierto de quien llega a Rust y toca texto es descubrir que hay dos tipos de cadena: String y &str. No es redundancia ni deuda histórica: es el ownership aplicado a las cadenas. String es el dueño de un buffer en el heap que puede crecer y mutar; &str es una vista prestada e inmutable sobre bytes que pertenecen a otro. Entender esta pareja —y por qué casi ninguna función bien escrita pide un String— es entender de golpe cómo Rust organiza todos sus datos.

Dos tipos para una idea: dueño y préstamo

Un String guarda en el stack tres palabras: un puntero al buffer del heap, la longitud en bytes y la capacidad reservada. Es, literalmente, un Vec<u8> con una garantía extra grabada en su tipo: sus bytes son siempre UTF-8 válido. En una plataforma de 64 bits, size_of::<String>() vale 24, tres usize juntos. Es el dueño: crece, muta y libera su buffer al morir.

Un &str es un puntero gordo (fat pointer) de dos palabras: la dirección del primer byte y la longitud de la porción, en bytes. No lleva capacidad porque no posee nada, y por eso no puede crecer. size_of::<&str>() vale 16. Un &str no apunta a un String: apunta directamente a los bytes, sean del heap de un String, del segmento de solo lectura del binario o del stack.

fn main() {
    let duena: String = String::from("hola"); // dueña: ptr + len + cap, buffer en el heap
    let vista: &str = &duena;                  // vista: ptr + len, mira los bytes de `duena`

    println!("{duena} mide {} bytes", duena.len());
    println!("la vista dice {vista}");
} // aquí muere `duena` y se libera su buffer; `vista` ya había terminado su préstamo

Que String sea “un Vec<u8> con invariante” no es una metáfora: comparte su estrategia de crecimiento. Además del puntero y la longitud, guarda una capacidad, cuántos bytes tiene reservados, que suele ser mayor que los que usa. Cuando añades texto y no cabe, String reserva un buffer mayor —típicamente el doble—, copia lo viejo y libera lo anterior. Ese realojo amortizado es lo que hace que acumular carácter a carácter salga, de media, a coste constante, y es exactamente la razón por la que un dueño necesita tres palabras y una vista solo dos.

let mut s = String::with_capacity(8);  // reserva 8 bytes por adelantado, longitud 0
s.push_str("hola");                     // cabe: no realoja
println!("len {} / cap {}", s.len(), s.capacity()); // len 4 / cap 8
s.push_str(" y mucho más texto");       // no cabe: realoja a un buffer mayor y copia

El literal ya es una vista, no un dueño

Un literal como "hola" no es un String. Su tipo es &'static str: una vista a bytes que el compilador incrusta en la sección de solo lectura del binario. Esos bytes viven tanto como el proceso —de ahí el lifetime 'static— y por eso no se reservan ni se liberan: ya estaban ahí, horneados en el ejecutable. Escribir un literal no toca el heap.

let saludo = "hola";               // &'static str: cero reservas, apunta al binario
let poseido = saludo.to_string();  // AHORA sí: copia esos bytes a un buffer propio en el heap

Esta distinción explica un malentendido habitual: crear un String a partir de un literal siempre copia. El literal vive en memoria inmutable y compartida; para tener algo que puedas hacer crecer necesitas tu propio buffer, y conseguirlo cuesta una reserva y un memcpy. No es gratis, y por eso Rust te obliga a pedirlo explícitamente en lugar de convertir a tus espaldas.

Hay una consecuencia sutil y agradable: como un &str no posee nada, copiarlo es trivial —duplica dos palabras, puntero y longitud, sin tocar el heap— y por eso &str es Copy. Puedes pasar la misma vista a diez funciones sin un solo clone ni un move que te compliquen la vida; todas comparten los mismos bytes de solo lectura. El dueño, en cambio, no es Copy: ceder un String es moverlo, porque solo puede haber un responsable de liberar ese buffer.

Por qué toda función bien escrita pide un str

Aquí está la pieza que lo une todo: String implementa Deref<Target = str>. Gracias a esa coerción de deref, allí donde se espera un &str, un &String se convierte solo, sin coste ni sintaxis. La consecuencia es una regla de diseño casi universal: acepta &str, no &String.

fn saludar(nombre: &str) {    // pide la vista más general que existe
    println!("Hola, {nombre}");
}

fn main() {
    let poseido = String::from("Ada");
    saludar(&poseido);        // &String -> &str por coerción de deref
    saludar("Turing");        // &'static str encaja directo, sin reservar nada
}

Si saludar pidiera &String, la segunda llamada no compilaría: obligarías a todo el que quisiera saludar a construir un String en el heap solo para pasártelo, aunque ya tuviera un literal perfecto. Pedir &str acepta ambos mundos con una sola firma. La otra cara del idioma es la simétrica: devuelve String cuando la función produce texto nuevo, porque el llamador necesita poseer y quizá seguir modificando lo que le entregas.

Esa misma coerción explica otro regalo silencioso: puedes llamar cualquier método de str directamente sobre un String. Cuando escribes poseido.len() o poseido.contains("d"), Rust no encuentra esos métodos en String —están definidos en str—, así que aplica deref automático, convierte &String en &str y los resuelve ahí. Un String hereda de facto toda la superficie de métodos de str sin que ninguno se duplique: la coerción de deref no solo aligera las firmas, también funde las dos API en una sola de cara a quien las usa.

flowchart LR
s[String con ptr len cap] -->|posee y libera| buf[Buffer UTF-8 en el heap]
v[str con ptr len] -->|mira sin poseer| buf
lit[str estatico con ptr len] -->|mira| ro[Bytes en el binario de solo lectura]

Cuándo cada uno, en una frase

Necesitas un String cuando el texto tiene que sobrevivirte, crecer o cambiar: acumular en un bucle, construir con format!, guardarlo en un struct que posee sus datos, devolverlo de una función que lo fabrica. Te basta un &str cuando solo vas a mirar: recibir un parámetro de lectura, devolver una porción de algo que el llamador ya posee, comparar, buscar, recortar. La duda “¿String o &str?” es en el fondo la pregunta de ownership de siempre —¿poseo o tomo prestado?— disfrazada de texto.

El caso de acumular lo condensa todo. El resultado tiene que poseer sus bytes porque crece en cada vuelta, así que es un String; cada pieza que le añades solo se lee, así que entra como &str. La firma cae sola en cuanto separas quién posee de quién solo mira:

fn unir(piezas: &[&str]) -> String {  // pide vistas, entrega un dueño nuevo
    let mut acc = String::new();      // el acumulador POSEE: va a crecer
    for p in piezas {
        acc.push_str(p);              // cada pieza solo se lee: basta la vista
    }
    acc                               // se mueve la PROPIEDAD al llamador
}

No hay que deliberar caso por caso: en cuanto etiquetas cada dato como “dueño” o “vista”, los tipos de la firma dejan de ser una elección y pasan a ser una consecuencia.