some: el tipo que el compilador conoce y tú no

some View parece una forma vaga de decir “algo que es una vista”, y esa lectura, aunque cómoda, es falsa. No hay nada vago en un tipo opaco: el compilador conoce el tipo concreto con total precisión, lo usa para especializar el código, para verificar la igualdad y para eliminar toda indirección. Lo único que ocurre es que el tipo no aparece escrito en la firma. some no es imprecisión: es ocultación deliberada de información que sí existe, un cortafuegos entre la implementación y quien la usa, con precio cero en tiempo de ejecución.

Un tipo concreto con la cara tapada

Un tipo opaco declara un contrato de salida: devuelvo un tipo, siempre el mismo, que conforma a este protocolo, y no te digo cuál.

protocol Figura {
    var area: Double { get }
}

struct Rectangulo: Figura {
    let ancho: Double, alto: Double
    var area: Double { ancho * alto }
}

func figuraUnidad() -> some Figura {   // el compilador sabe: Rectangulo
    Rectangulo(ancho: 1, alto: 1)      // quien llama solo sabe: es una Figura
}

Compáralo con la forma genérica clásica y verás que la dirección de la elección se ha invertido:

// Generico normal: quien LLAMA elige T
func vacia<T: Figura>() -> T { ... }        // imposible de implementar en general

// Tipo opaco: quien IMPLEMENTA elige el tipo
func figuraUnidad() -> some Figura { ... }  // natural y verificable

Por eso a los tipos opacos se les llama genéricos invertidos o genéricos inversos. En un genérico normal, el parámetro de tipo es una entrada que fija el punto de llamada; en un opaco, es una salida que fija el cuerpo de la función. La firma es idéntica en apariencia y opuesta en semántica.

Identidad de tipo: la propiedad que lo cambia todo

Aquí está la diferencia decisiva frente a una caja existencial. Un tipo opaco preserva la identidad del tipo: el compilador sabe que dos invocaciones de la misma función producen valores del mismo tipo, aunque tú no puedas nombrarlo.

func par() -> some Equatable { 42 }

let a = par()
let b = par()
print(a == b)   // compila: el compilador sabe que ambos son Int

Ese == es imposible sobre un existencial, porque Equatable tiene un requisito de Self y dos cajas podrían guardar tipos distintos. Con some, la promesa “siempre el mismo tipo” hace que el requisito de Self quede satisfecho estáticamente. La identidad no es un detalle: es lo que permite que un tipo opaco conforme al protocolo, se use en genéricos, satisfaga requisitos con tipos asociados y participe en operaciones binarias.

La contrapartida es la restricción que todo el mundo descubre a base de errores: todas las rutas de retorno deben producir el mismo tipo concreto.

func figura(grande: Bool) -> some Figura {
    if grande { return Rectangulo(ancho: 10, alto: 10) }
    else      { return Circulo(radio: 3) }        // error: tipos distintos
}

No es una limitación arbitraria, es la consecuencia directa de la promesa. Si dos llamadas pudieran devolver tipos diferentes, la identidad se rompería y == dejaría de tener sentido. La solución idiomática cuando de verdad necesitas ramificar es envolver ambas ramas en un tipo genérico único —el patrón que emplea internamente el constructor de vistas de SwiftUI, que empaqueta el if en un tipo condicional parametrizado por las dos alternativas—.

some en parámetros: genéricos con otra sintaxis

Desde Swift 5.7, some también puede aparecer en la posición de un parámetro. Ahí su significado es exactamente el de un parámetro genérico anónimo.

func imprimirArea(de figura: some Figura) { print(figura.area) }

// Es estrictamente equivalente a:
func imprimirArea<T: Figura>(de figura: T) { print(figura.area) }

Fíjate en la simetría y en la asimetría. En entrada, some significa “quien llama elige el tipo”. En salida, significa “yo elijo el tipo”. Es la misma palabra porque en ambos casos describe un tipo concreto y único, oculto tras el protocolo; cambia quién ejerce la elección, y eso lo determina la posición.

También puedes acotar los tipos asociados sin abandonar la opacidad, gracias a los tipos asociados primarios:

func enteros() -> some Collection<Int> {    // opaco, pero con Element fijado
    [1, 2, 3]
}

func sumar(_ xs: some Sequence<Int>) -> Int {
    xs.reduce(0, +)
}

flowchart LR
L[Quien llama] -->|elige el tipo| PE[some en parametro]
I[Quien implementa] -->|elige el tipo| PS[some en retorno]
PE --> U[Un unico tipo concreto en cada uso]
PS --> U
U --> C[Identidad de tipo preservada]
C --> D[Despacho estatico y posible especializacion]
D --> Z[Sin caja y sin asignacion de memoria]
style U fill:#a6e3a1,color:#11111b
style C fill:#89b4fa,color:#11111b
style Z fill:#cba6f7,color:#11111b

Coste cero y sus letras pequeñas

Un tipo opaco no introduce ninguna estructura en ejecución. No hay caja, no hay asignación de memoria, no hay salto indirecto obligatorio: el código generado es el mismo que si hubieras escrito el tipo concreto a mano. La opacidad vive enteramente en el comprobador de tipos.

func contador() -> some Collection<Int> { Array(1...100) }

let c = contador()
let total = c.reduce(0, +)   // se compila igual que si c fuese [Int]

El opaco también se propaga hacia dentro de estructuras compuestas. Desde Swift 5.7 puedes colocarlo en posiciones estructurales del tipo de retorno, no solo en la raíz, lo que permite devolver tuplas u opcionales de tipos ocultos sin renunciar a la identidad de cada uno:

func partes() -> (some Collection<Int>, some Figura) {
    ([1, 2, 3], Rectangulo(ancho: 1, alto: 1))
}

func quiza() -> (some Figura)? {
    Rectangulo(ancho: 2, alto: 2)
}

La letra pequeña, que casi nunca se cuenta, es que coste cero describe el modelo, no siempre el binario. El código genérico sin especializar también usa tablas en ejecución; lo que garantiza some es que el optimizador puede especializar, porque conoce el tipo. Dentro de un módulo, con optimización de módulo completo, la especialización es la norma. A través de fronteras de módulo, sin @inlinable ni resiliencia relajada, el compilador puede verse obligado a emitir la versión genérica no especializada. La diferencia con any sigue siendo cualitativa —no hay caja ni borrado—, pero conviene no confundir el modelo con la garantía absoluta.