@autoclosure y closures como control de flujo

Swift evalúa los argumentos antes de entrar en la función. Siempre, sin excepción, con una única salida: convertir el argumento en un closure para que la función decida si lo ejecuta y cuándo. @autoclosure automatiza esa conversión de manera que el llamante no vea las llaves, y el resultado es una construcción con dos caras muy distintas. La cara luminosa es que permite escribir funciones que se comportan como estructuras del lenguaje —cortocircuitos, valores por defecto que no se calculan si no hacen falta, aserciones que se evaporan en producción— y esa cara es tan valiosa que operadores que todo el mundo da por primitivos están de hecho definidos con ella en la biblioteca estándar. La cara oscura es que hace desaparecer del punto de llamada la información de que una expresión puede no ejecutarse nunca, o ejecutarse tres veces, y esa desaparición convierte un efecto secundario inocente en un error que nadie ve al leer.

La transformación, y dónde ocurre

Un parámetro marcado con @autoclosure debe tener tipo función sin parámetros. En el punto de llamada, el compilador toma la expresión escrita y la envuelve en un closure automáticamente, de modo que el texto se lee como si el argumento fuera un valor y la semántica es la de un cálculo aplazado.

func registrar(_ mensaje: @autoclosure () -> String, si condicion: Bool) {
  guard condicion else { return }
  print(mensaje())
}

registrar(construirInformeCostoso(), si: nivelDeDetalle == .completo)

La llamada no tiene llaves y sin embargo construirInformeCostoso no se ejecuta salvo que la condición sea cierta: la función adquiere así una capacidad que en la mayoría de lenguajes está reservada a las macros o a las palabras clave. Conviene fijar dos hechos que evitan la mitad de las confusiones. El primero es que el atributo describe el parámetro, no el argumento: quien llama no sabe, leyendo la llamada, que se está produciendo la conversión. El segundo es que la expresión envuelta puede ejecutarse cero, una o varias veces, según lo que haga el cuerpo, y que nada en el punto de llamada lo indica.

func repetir(_ accion: @autoclosure () -> Void, veces n: Int) {
  for _ in 0..<n { accion() }
}

var contador = 0
repetir(contador += 1, veces: 3)   // contador vale 3

Esa línea es sintácticamente indistinguible de una llamada normal y sin embargo incrementa tres veces. Es el argumento central en contra del uso indiscriminado del atributo, y volveremos a él al final.

El cortocircuito no es magia del compilador

La intuición extendida es que los operadores lógicos cortocircuitan porque el compilador los trata de forma especial. En Swift no es así: son funciones normales de la biblioteca estándar, y lo que las hace cortocircuitar es exactamente @autoclosure.

// Aproximacion a la declaracion de la biblioteca estandar
static func && (
  lhs: Bool,
  rhs: @autoclosure () throws -> Bool
) rethrows -> Bool {
  lhs ? try rhs() : false
}

El operando derecho llega sin evaluar y solo se evalúa si el izquierdo lo exige. El mismo mecanismo sostiene el operador de fusión de nilos, cuya utilidad depende por completo de que el valor por defecto no se calcule cuando el opcional trae contenido.

func ?? <T>(
  opcional: T?,
  porDefecto: @autoclosure () throws -> T
) rethrows -> T {
  switch opcional {
  case let valor?: return valor
  case nil: return try porDefecto()
  }
}

let config = cache[clave] ?? leerDelDisco(clave)   // no toca el disco si hay cache

Que estos operadores sean funciones ordinarias y no sintaxis privilegiada es una propiedad notable del diseño de Swift, y @autoclosure es la pieza que la hace posible. Sin él, el lenguaje necesitaría casos especiales en el compilador para tres o cuatro operadores, y ningún programador podría escribir el quinto.

El caso ejemplar: assert y precondition

La demostración más limpia del valor del atributo está en las funciones de comprobación de la biblioteca estándar, cuya firma aproximada es la siguiente.

func assert(
  _ condition: @autoclosure () -> Bool,
  _ message: @autoclosure () -> String = String(),
  file: StaticString = #fileID,
  line: UInt = #line
)

Los dos primeros parámetros son diferidos, y eso permite algo que ninguna otra forma consigue: en compilaciones optimizadas de lanzamiento, assert no evalúa ni la condición ni el mensaje. No es que descarte el resultado, es que la expresión no llega a ejecutarse. Una aserción que recorre una colección entera para comprobar una invariante, o que construye un mensaje concatenando la descripción de veinte objetos, cuesta exactamente cero en producción.

assert(
  inventario.allSatisfy { $0.cantidad >= 0 },
  "Inventario con cantidades negativas: \(inventario.filter { $0.cantidad < 0 })"
)

Escrita sin evaluación diferida, esta línea recorrería la colección dos veces y construiría la cadena completa en cada ejecución, incluso cuando la condición se cumple y el mensaje no se usa. La familia de comprobaciones aprovecha esa propiedad con matices que conviene distinguir.

La regla de uso que se deriva es precisa: assert documenta invariantes internas cuya violación indica un fallo de programación y cuya comprobación puede permitirse desaparecer; precondition valida contratos cuyo incumplimiento haría inseguro continuar, y por eso sobrevive a la optimización. Elegir mal significa o bien pagar en producción por comprobaciones prescindibles, o bien continuar ejecutando con una invariante rota porque la comprobación se desvaneció.

Construir control de flujo, y saber cuándo no

Con la técnica en la mano, escribir estructuras propias es directo. El patrón útil aparece siempre que un argumento sea caro de producir y su necesidad dependa de una decisión que la función toma.

extension Optional {
  func oLanzar(_ error: @autoclosure () -> Error) throws -> Wrapped {
    guard let valor = self else { throw error() }
    return valor
  }
}

let usuario = try sesion.usuario.oLanzar(ErrorDeSesion.sinUsuario(recopilarContexto()))

También es la forma correcta de construir un registro por niveles donde la interpolación de la cadena solo ocurra si el nivel está activo, que es una de las optimizaciones más rentables y menos aplicadas en aplicaciones con instrumentación densa.

Ahora el argumento en contra, que es serio y debe pesar más que el entusiasmo. @autoclosure rompe la correspondencia entre lo que se lee y lo que ocurre. Quien mira una llamada ve una expresión evaluada; en realidad ve una expresión que quizá no se evalúe, o que se evalúe varias veces, y la única manera de saberlo es ir a leer la firma. Cuando el argumento tiene efectos secundarios —una escritura, un incremento, una llamada a red— esa opacidad produce errores que ningún tipo detecta. De ahí un criterio de diseño con tres condiciones que conviene exigir juntas.

• El argumento debe ser una expresión pura y cara, no una acción con efectos.
• La función debe leerse como una construcción del lenguaje, no como una operación cualquiera.
• El nombre debe sugerir la condicionalidad por sí mismo, como hacen assert o el operador de fusión.

Si alguna de las tres falla, el closure explícito con sus llaves visibles es la opción correcta, porque paga con cuatro caracteres una honestidad que el lector agradecerá.

flowchart LR
E[Expresion en el sitio de llamada] -->|autoclosure| C[Closure sin parametros]
C --> F[Cuerpo de la funcion decide]
F -->|no la invoca| Z[Coste cero]
F -->|la invoca una vez| U[Evaluacion normal]
F -->|la invoca en bucle| M[Evaluacion repetida]
style Z fill:#a6e3a1,color:#11111b
style M fill:#f38ba8,color:#11111b