Cuándo cada uno: la regla y los casos forzados

Las dos palabras clave se parecen tanto en la sintaxis que invitan a tratarlas como sinónimos con distinto sabor, y no lo son: eligen mundos distintos. Afortunadamente, la decisión no requiere análisis caso por caso la mayoría de las veces, porque existe una regla por defecto sólida y un puñado corto de situaciones donde el compilador decide por ti. Este es el mapa: primero la regla, luego los casos forzados en ambas direcciones, y por último la zona gris —parámetros, propiedades almacenadas, superficie pública— donde la elección deja de ser técnica y pasa a ser de diseño.

La regla en una frase

Empieza siempre por some; cambia a any solo cuando el compilador te lo exija o cuando necesites explícitamente que el tipo varíe en ejecución.

// Por defecto
func procesar(_ figura: some Figura) -> Double { figura.area }
func construir() -> some Figura { Circulo(radio: 1) }

// Excepcion justificada
var escena: [any Figura] = []      // tipos mezclados: no hay alternativa

La razón de que el opaco sea el valor por defecto no es dogmática: es que some conserva más información. Preserva la identidad del tipo, permite requisitos con Self, habilita la especialización, evita la caja y el conteo de referencias, y no te cierra ninguna puerta salvo la heterogeneidad. Elegir any sin necesitarlo es descartar información gratuitamente y pagar por el descarte.

Los casos en que solo compila any

Son cuatro, y merece la pena memorizarlos porque cubren casi todo el uso legítimo del existencial.

Colecciones heterogéneas. Un array genérico es homogéneo por construcción; mezclar conformantes exige un tipo que los abarque.

let figuras: [any Figura] = [Circulo(radio: 1), Rect(l: 2)]

Almacenamiento cuyo tipo cambia con el tiempo. Una propiedad opaca queda ligada a un único tipo durante toda la vida del programa; si la reasignación debe cambiar de tipo, necesitas una caja.

final class Lienzo {
    var actual: any Figura = Circulo(radio: 1)
    func reemplazar(con nueva: any Figura) { actual = nueva }
}

Recursión y grafos. Un nodo que apunta a otro nodo cuyo contenido varía no puede fijar ese tipo en compilación sin propagar parámetros genéricos por toda la estructura hasta hacerla inservible.

Decisión en ejecución. Fábricas, registros de plugins, descodificación de datos externos, tablas de estrategias indexadas por una cadena: en todos ellos el tipo concreto es un resultado del programa, no una entrada del compilador.

func figuraDesde(_ nombre: String) -> any Figura {
    nombre == "circulo" ? Circulo(radio: 1) : Rect(l: 1)
}

Fíjate en que este último ejemplo no puede escribirse con some: dos ramas de retorno con tipos distintos violan la identidad de tipo.

Los casos en que solo compila some

La dirección contraria tiene una causa única de la que todo lo demás se deriva: la caja borra la identidad del tipo, y hay requisitos que la necesitan.

Requisitos con Self en posición binaria. Comparar, sumar, combinar dos valores exige que ambos sean del mismo tipo, y dos cajas no lo garantizan.

func maximo(_ a: some Comparable, _ b: some Comparable) -> Bool { true }  // ojo
func maximoBien<T: Comparable>(_ a: T, _ b: T) -> T { a > b ? a : b }     // asi si

Ese primer ejemplo revela un matiz importante: dos some distintos en la misma firma son dos parámetros genéricos independientes, no uno compartido. Cuando necesitas que dos argumentos sean del mismo tipo, la sintaxis genérica explícita sigue siendo la única que lo expresa.

Tipos asociados en posición de entrada. Insertar en una colección existencial es imposible sin abrirla, porque el elemento entra y su tipo es desconocido.

func rellenar<C: RangeReplaceableCollection>(_ c: inout C, con x: C.Element) {
    c.append(x)          // con un existencial cerrado esto no compilaria
}

Conformidad a otro protocolo. Si necesitas que el valor satisfaga un requisito genérico o alimente una restricción, recuerda que la caja no conforma al protocolo que contiene.

Rutas críticas de rendimiento. No es una imposibilidad del compilador sino una del presupuesto, pero funciona igual de bien como criterio: en un bucle que se ejecuta millones de veces, el existencial introduce indirección, bloquea la inserción en línea y añade tráfico de conteo de referencias.

flowchart TB
Q1{Necesitas mezclar tipos distintos en una coleccion o variable}
Q1 -->|Si| ANY[Usa any]
Q1 -->|No| Q2{El tipo concreto se decide con datos de ejecucion}
Q2 -->|Si| ANY
Q2 -->|No| Q3{Hay recursion o referencias ciclicas entre tipos}
Q3 -->|Si| ANY
Q3 -->|No| SOME[Usa some o un generico explicito]
SOME --> N1[Identidad de tipo preservada]
SOME --> N2[Sin caja y sin despacho indirecto]
ANY --> N3[Flexibilidad a cambio de borrado y coste]
style SOME fill:#a6e3a1,color:#11111b
style ANY fill:#89b4fa,color:#11111b
style N3 fill:#f9e2af,color:#11111b

La zona gris: parámetros, almacenamiento y API pública

En parámetros, la respuesta es casi siempre some. Un parámetro existencial obliga a quien llama a construir una caja aunque tenga el tipo concreto a mano, y a ti a operar con despacho dinámico dentro. La excepción es cuando el parámetro se va a almacenar en una propiedad heterogénea: entonces la caja se construirá igualmente y recibirla ya encajada evita una conversión redundante.

En propiedades almacenadas, la pregunta correcta es si el tipo debe poder cambiar. Si el tipo es fijo para cada instancia, un parámetro genérico en el tipo contenedor es superior; si debe variar por instancia o con el tiempo, el existencial es la herramienta.

// El tipo es fijo por instancia: parametrizalo
struct Marco<F: Figura> { let contenido: F }

// El tipo varia: encajalo
struct MarcoDinamico { var contenido: any Figura }

En API pública de biblioteca, la elección tiene un efecto adicional que no aparece en el rendimiento: la superficie de compromiso. Un retorno some te deja cambiar el tipo interno en la próxima versión sin romper a nadie; un retorno concreto no. Y un parámetro some acepta cualquier conformante sin obligar a tus usuarios a encajar nada.

Queda una asimetría que sorprende a quien llega desde otros lenguajes: no existe un some en la declaración de un requisito de protocolo. Si lo que quieres es que cada conformante fije su propio tipo de salida, la herramienta no es el opaco sino el tipo asociado, y el opaco aparece después, al implementarlo.

protocol Fabrica {
    associatedtype Producto: Figura
    func crear() -> Producto
}

struct FabricaCirculos: Fabrica {
    func crear() -> some Figura { Circulo(radio: 1) }   // resuelve el asociado
}