borrowing y consuming: la convención hecha explícita

Toda llamada a función plantea una pregunta que el código fuente de Swift nunca hacía visible: cuando el argumento cruza la frontera, ¿quién queda a cargo de destruirlo? Hay solo tres respuestas posibles y el compilador lleva desde 2014 eligiendo entre ellas por su cuenta. El llamante conserva la propiedad y presta el valor mientras dura la llamada. El llamante cede la propiedad y se desentiende. O el llamante presta acceso exclusivo de escritura y recupera el valor mutado al terminar. borrowing, consuming e inout son exactamente esas tres respuestas, escritas por fin donde se pueden leer.

Las tres promesas

Un parámetro borrowing establece que el llamado obtiene acceso de solo lectura durante la llamada y ni un instante más. El llamante garantiza que el valor sigue vivo mientras dure; el llamado no incrementa ningún recuento, no puede mutar el parámetro y no puede quedárselo: guardarlo en una propiedad, capturarlo en un cierre que escapa o devolverlo requiere una copia, y en un tipo no copiable eso es sencillamente ilegal.

Un parámetro consuming establece lo contrario: la propiedad se transfiere. El llamado hereda la obligación de destruir el valor, puede almacenarlo sin copiarlo y puede consumirlo dentro. A cambio, el llamante pierde el derecho a usarlo después de la llamada.

inout es la tercera vía y no es ninguna de las anteriores: un préstamo mutable exclusivo. La ley de exclusividad garantiza que mientras dura ese acceso nadie más, ni siquiera el propio llamante, puede leer o escribir esa posición de memoria. No hay transferencia de propiedad en ningún momento: el valor sale y vuelve, y el responsable de destruirlo sigue siendo quien lo era antes de la llamada.

struct Registro: ~Copyable {
    let bytes: UnsafeMutableRawBufferPointer
}

func inspeccionar(_ r: borrowing Registro) -> Int { r.bytes.count }
func archivar(_ r: consuming Registro) { /* se queda con el */ }

func uso(_ r: consuming Registro) {
    _ = inspeccionar(r)   // prestamo: r sigue siendo mio
    archivar(r)           // transferencia: aqui termina mi derecho
    // inspeccionar(r)    // ERROR: r ya fue consumido
}

El diagnóstico de la última línea es la esencia del modelo. No dice que la operación sea cara: dice que el valor ya no te pertenece.

Las convenciones por omisión

Escribir estos modificadores rara vez cambia la convención elegida, porque las omisiones ya son las razonables. Un parámetro normal de una función o de un método es borrowing por omisión. Los parámetros de un inicializador y el valor entrante de un asignador de propiedad son consuming, porque su trabajo consiste precisamente en quedarse con lo que reciben. Un método mutating toma su receptor como inout, y un método puede declararse borrowing func o consuming func para fijar la convención de self.

De ahí se sigue una regla práctica: en tipos copiables, anotar suele ser redundante, y su efecto real se limita a los casos donde la convención por omisión no coincide con lo que el cuerpo hace con el valor. Dicho de otro modo, escribir borrowing en un parámetro corriente no cambia nada salvo la documentación; escribir consuming sí cambia el código generado, porque contradice la omisión.

struct Lote {
    private(set) var elementos: [Int] = []

    // Estilo constructor: al consumir self no hay dos duenos del bufer,
    // de modo que la mutacion no dispara copia al escribir.
    consuming func agregando(_ x: Int) -> Lote {
        var copia = self
        copia.elementos.append(x)
        return copia
    }
}

El patrón encadenado clásico paga una copia del búfer en cada eslabón porque el receptor prestado sigue vivo en el llamante mientras se muta la copia. Al declarar el método consuming, el receptor deja de estar vivo fuera y la comprobación de unicidad tiene éxito.

Es el ejemplo canónico porque muestra que la anotación no elimina trabajo: reubica una decisión. El coste de la copia no desapareció por escribir una palabra, desapareció porque la palabra le comunicó al compilador un hecho que antes no podía deducir, a saber, que nadie iba a usar el receptor después.

Pista en lo copiable, contrato en lo no copiable

La misma palabra clave tiene dos pesos muy distintos según el tipo al que se aplica, y confundirlos es la fuente principal de malentendidos.

En un tipo copiable, la semántica del programa no cambia. Si una función pide consuming y el llamante todavía necesita el valor, el compilador copia y todos quedan satisfechos; si pide borrowing y el cuerpo necesita almacenarlo, el compilador copia también. La copia es siempre una salida disponible, así que el modificador funciona como una directiva de rendimiento: ajusta dónde ocurre el trabajo, no qué significa el programa.

En un tipo no copiable esa salida no existe. Sin copia posible, el modificador se convierte en la única forma de decir si el valor sobrevive a la llamada, y el verificador de préstamos lo hace cumplir. Aquí borrowing y consuming no son adorno: son parte de la firma tanto como el tipo de retorno.

De esa asimetría se sigue una consecuencia de compatibilidad que afecta al diseño de bibliotecas. Cambiar un parámetro copiable de una convención a otra no rompe a ningún llamante, porque el compilador ajusta las copias en cada sitio de llamada; hacer lo mismo en un tipo no copiable rompe a todo el que usara el valor después de la llamada. En el primer caso estás retocando el rendimiento, en el segundo estás modificando el contrato público.

flowchart TB
q1[El cuerpo necesita mutar el valor del llamante]
q1 -->|si| io[inout prestamo mutable exclusivo]
q1 -->|no| q2[El cuerpo se queda con el valor tras la llamada]
q2 -->|si| co[consuming transferencia de propiedad]
q2 -->|no| bo[borrowing prestamo de solo lectura]
co --> n1[En no copiables el llamante pierde el acceso]
bo --> n2[En no copiables no se puede almacenar ni devolver]
style bo fill:#a6e3a1,color:#11111b
style co fill:#cba6f7,color:#11111b
style io fill:#89b4fa,color:#11111b

Dirigir la vida a mano

Los modificadores gobiernan las fronteras de función; dentro de una función, dos operadores permiten intervenir directamente. El operador consume termina la vida de una variable en ese punto exacto y entrega su valor: lo que quedaba de esa variable deja de existir para el compilador, y usarla después es un error.

func enviar(_ carga: consuming [UInt8]) { /* ... */ }

func rutina() {
    var carga = generar()
    ajustar(&carga)
    enviar(consume carga)   // fin explicito de la vida de la variable
    // print(carga)         // ERROR: uso despues de consumir
}

Sin el operador, el compilador debe suponer que la variable puede usarse más adelante y mantenerla viva hasta el final de su ámbito. Con él, la propiedad se reenvía a la llamada y desaparece cualquier necesidad de conservar el valor. Su simétrico es el operador copy, que fuerza una copia explícita cuando el análisis habría reenviado la propiedad y todavía necesitas el original.

Hay dos matices que conviene tener presentes. El primero es que consume sobre un tipo copiable es una petición de fin de vida, no una prohibición absoluta: sirve para ayudar al optimizador y para documentar la intención, y sobre variables globales o propiedades de clase el compilador puede necesitar copiar de todos modos. El segundo es que el modelo trabaja sobre variables locales y parámetros; una propiedad almacenada de una clase no se puede consumir, porque el objeto sigue existiendo y su campo debe quedar en un estado válido.

El análisis que hay detrás merece un nombre, porque explica los diagnósticos que verás: el compilador construye el grafo de flujo de la función y comprueba, para cada uso de una variable, que no exista ningún camino de ejecución en el que ese uso venga después de un consumo. Por eso el error habla de una línea concreta y señala además dónde ocurrió el consumo, y por eso una transferencia dentro de una rama condicional invalida la variable en todo lo que siga a la unión de las ramas, aunque la otra rama no consumiera nada. El verificador razona sobre caminos, no sobre líneas.