La lista de captura

Todo lo que un closure captura lo captura por defecto y con fuerza: enlaza la variable, no copia el valor, y mantiene vivo lo que apunta mientras él viva. Ese comportamiento por defecto es correcto la mayoría de las veces y catastrófico en un caso concreto y frecuentísimo, el del objeto que guarda un closure que a su vez lo sostiene a él. La lista de captura es la herramienta con la que Swift permite intervenir en esa mecánica, y su sintaxis es engañosamente pequeña: unos corchetes antes de los parámetros. Dentro caben dos operaciones distintas que conviene no confundir nunca, porque resuelven problemas diferentes: copiar un valor en el instante de la creación, y debilitar un enlace para que no impida morir a su destino. Confundirlas produce o bien fugas silenciosas o bien caídas en tiempo de ejecución, y ninguna de las dos avisa en el momento de escribir la línea.

La lista como secuencia de enlaces evaluados ya

La lista de captura va entre corchetes inmediatamente antes de los parámetros y de la palabra in. Cada entrada declara una constante nueva, visible solo dentro del closure, cuyo valor se calcula en el momento de crear el closure y no en el de ejecutarlo. Ese desplazamiento temporal es la primera de sus dos funciones y resuelve por completo el problema de la lectura tardía.

var mensaje = "hola"

let tarde = { print(mensaje) }
let ahora = { [mensaje] in print(mensaje) }

mensaje = "adios"
tarde()   // adios
ahora()   // hola

La entrada puede renombrar y puede contener una expresión completa, lo que la convierte en un lugar razonable para congelar estado derivado sin ensuciar el ámbito exterior.

let manejador = { [identificador = modelo.id, instante = Date.now] in
  registrar(identificador, en: instante)
}

Conviene ser exacto con la semántica de la copia, porque el atajo mental la lista de captura copia solo es cierto para tipos valor. Para un tipo referencia, lo que se copia es la referencia, no el objeto: [modelo] sigue reteniendo con fuerza el mismo objeto de siempre. La lista congela a qué se apunta, no el contenido de lo apuntado. De ahí que resolver un ciclo de retención nunca se consiga copiando, sino con la segunda función de la lista: los especificadores de fuerza.

El ciclo de retención clásico

El caso canónico tiene tres elementos y una simetría fatal. Un objeto guarda un closure en una propiedad, y ese closure usa una propiedad del objeto, con lo que captura self con fuerza. El objeto retiene al closure; el closure retiene al objeto. El conteo de referencias de ambos nunca llega a cero, y ninguno se libera jamás, aunque nadie más en el programa los conozca.

final class Reproductor {
  var titulo = "silencio"
  var alTerminar: (() -> Void)?

  func preparar() {
    alTerminar = {
      print("fin de \(self.titulo)")   // captura fuerte de self
    }
  }

  deinit { print("liberado") }
}

var r: Reproductor? = Reproductor()
r?.preparar()
r = nil        // no imprime "liberado": el ciclo lo impide

Lo que hace peligroso a este patrón no es su dificultad conceptual sino su invisibilidad. No hay error de compilación, no hay aviso, no hay caída. El programa funciona; simplemente no devuelve la memoria, y el síntoma aparece semanas después como un crecimiento sostenido bajo navegación repetida, o como un manejador de un objeto ya cerrado que sigue reaccionando a eventos y produce efectos fantasma. Ese segundo síntoma suele ser más caro que el primero, porque se manifiesta como un fallo lógico y nadie lo relaciona con la memoria.

La cura es cortar una de las dos aristas, y por convención se corta la del closure hacia el objeto, porque la otra es la que expresa la relación de propiedad real.

alTerminar = { [weak self] in
  guard let self else { return }
  print("fin de \(self.titulo)")
}

weak frente a unowned

Los dos especificadores capturan sin retener. La diferencia está en qué ocurre cuando el destino muere antes que el closure, y esa diferencia es total.

La regla de decisión correcta no es usa siempre weak por seguridad, aunque sea el consejo más repetido, sino una comparación de tiempos de vida. Si el closure puede ejecutarse legítimamente después de que el objeto haya desaparecido —una respuesta de red que llega tarde, un temporizador, una notificación— entonces weak es lo apropiado y el opcional expresa una posibilidad real. Si el closure está garantizadamente contenido dentro del objeto y muere con él, unowned es más honesto: declara la invariante en el código y convierte su violación en un fallo ruidoso en vez de en un silencio.

final class Sesion {
  private var cierre: (() -> Void)!

  init() {
    // El closure es propiedad de self y no puede sobrevivirle
    cierre = { [unowned self] in self.limpiar() }
  }

  func limpiar() { }
}

La objeción evidente es que unowned puede provocar una caída. Es cierta y es precisamente su valor: una caída inmediata en el punto exacto del error es infinitamente más barata de diagnosticar que un weak self que se evalúa a nil y hace que el closure retorne pronto en silencio, dejando una operación a medias que nadie sabe que no ocurrió. El coste de weak no es de rendimiento, es de ocultación: el guard let self else { return } convierte un error de tiempo de vida en una rama vacía sin traza.

Los patrones modernos y sus matices

Desde Swift 5.8 se puede escribir guard let self else { return } sin renombrar, y desde Swift 5.3 la lista de captura admite [weak self] combinado con desenvolvimiento inmediato. La forma idiomática actual es corta y merece leerse con atención a qué hace cada parte.

cargar { [weak self] resultado in
  guard let self else { return }
  self.estado = .cargado(resultado)
}

Hay un caso donde la costumbre se vuelve contraproducente, y es el de las tareas estructuradas. Una Task no la retiene el objeto: la retiene el sistema de concurrencia hasta que termina. Capturar self con fuerza dentro de una Task no crea un ciclo, solo alarga la vida del objeto hasta el final de la tarea, que suele ser exactamente lo que se quiere si la tarea va a escribir en él. Escribir [weak self] en ese contexto produce, en el peor caso, que el trabajo se descarte a mitad porque el objeto murió y el guard cortó la ejecución, sin que nadie se entere.

// Habitualmente correcto: se quiere que self viva hasta terminar
Task { await self.refrescar() }

// Correcto solo si el trabajo es realmente descartable
Task { [weak self] in await self?.refrescarSiSigueVivo() }

La misma cautela vale para closures que no escapan: map, filter, forEach y compañía se ejecutan y desaparecen dentro de la llamada, así que no pueden formar un ciclo y no necesitan [weak self]. Escribirlo ahí es ruido que además obliga a un desenvolvimiento innecesario y confunde al lector sobre la naturaleza del closure.

flowchart LR
O[Objeto] -->|propiedad fuerte| C[Closure]
C -->|captura fuerte de self| O
O2[Objeto] -->|propiedad fuerte| C2[Closure]
C2 -.->|weak o unowned| O2
C2 --> L[Ambos se liberan]
style C fill:#f38ba8,color:#11111b
style L fill:#a6e3a1,color:#11111b