Índices y Substring: navegar sin romper el texto

La primera vez que intentas escribir el equivalente de acceder al quinto carácter de una cadena, Swift te dice que no. No hay un subíndice que acepte enteros y no lo habrá, y la respuesta oficial suele quedarse en que las cadenas son complicadas. La respuesta real es más interesante: ofrecer ese subíndice sería mentir sobre el coste, porque la operación es lineal y todo el mundo la escribiría como si fuera constante. En su lugar, Swift te obliga a manipular un tipo opaco cuya única función es hacer visible el recorrido, y a cambio te regala rebanadas que no copian nada. Las dos caras de ese trato, la incomodidad y el regalo, son el tema de esta lección.

Por qué no hay subíndice por entero

En un vector de elementos de tamaño fijo, llegar al elemento número cinco es aritmética: dirección base más cinco veces el tamaño. En una cadena UTF-8 segmentada en grafemas no hay ninguna aritmética posible, porque ni los escalares ocupan lo mismo ni los grafemas contienen el mismo número de escalares. Llegar al quinto grafema exige empezar por el primero y aplicar la segmentación cuatro veces. Un lenguaje puede ocultar eso tras un subíndice de aspecto inocente, y entonces cada bucle escrito por costumbre se vuelve cuadrático sin que nadie lo note; o puede negarse, y entonces el coste queda escrito en el código. Swift se niega.

let texto = "Hola, mundo"

let inicio = texto.startIndex
let quinto = texto.index(inicio, offsetBy: 4)
print(texto[quinto])                  // "a"

// Antes del final, nunca el final: endIndex esta una posicion mas alla
let ultimo = texto.index(before: texto.endIndex)
print(texto[ultimo])                  // "o"

// Version segura cuando el desplazamiento puede pasarse
if let seguro = texto.index(inicio, offsetBy: 40, limitedBy: texto.endIndex) {
  print(texto[seguro])
} else {
  print("fuera de rango")
}

Conviene fijar dos hechos desde el principio. endIndex no señala al último elemento sino a la posición siguiente al último, así que usarlo como subíndice es un error de programación que detiene el proceso. Y la variante limitada existe porque desplazarse más allá del final también lo es: en Swift, salirse de rango no devuelve un opcional por defecto, interrumpe la ejecución, y las funciones con la etiqueta de límite son la forma de convertir ese fallo en un valor con el que puedas razonar.

Qué es realmente un índice

Un String.Index no es un entero disfrazado. Guarda una posición dentro del almacenamiento UTF-8 del receptor, junto con información de cacheado sobre la vista y sobre la frontera de grafema en la que cayó. Esa carga extra es lo que permite que el mismo índice sirva para las distintas vistas de la cadena sin recalcular nada, y es también lo que lo ata a un almacenamiento concreto: un índice obtenido de una cadena y usado en otra distinta produce, en el mejor de los casos, un resultado sin sentido, y en el peor una interrupción del proceso. Los índices son válidos para la cadena que los generó y para las rebanadas que comparten su almacenamiento; nada más.

flowchart LR
S[String con buffer UTF8] --> I[String Index opaco]
I --> P[Desplazamiento en bytes]
I --> G[Frontera de grafema cacheada]
S --> SS[Substring como rebanada]
SS --> B[Comparte el mismo buffer]
B --> R[Los indices del padre siguen siendo validos]

De ahí se sigue la regla práctica: los índices no se guardan entre mutaciones. Si insertas o eliminas texto, los índices anteriores dejan de significar lo que significaban, aunque sigan siendo formalmente utilizables. Lo que sí puedes guardar sin miedo es un Range sobre una cadena inmutable, o mejor todavía, guardar la rebanada en sí y olvidarte de las posiciones.

Substring: la rebanada que no copia

Cuando cortas una cadena, Swift no te devuelve un String sino un Substring. La diferencia de tipo es deliberada y expresa una diferencia de propiedad: el Substring no tiene almacenamiento propio, apunta a un rango dentro del almacenamiento del padre y lo mantiene vivo mediante el conteo de referencias. Crear uno cuesta tiempo constante y cero bytes de copia, lo que hace que trocear un documento grande sea gratis mientras no conviertas nada.

let linea = "nombre=valor"

let clave = linea.prefix(while: { $0 != "=" })    // Substring
let resto = linea.drop(while: { $0 != "=" })      // Substring
let valor = resto.dropFirst()                     // Substring

print(type(of: clave))          // Substring
print(clave.startIndex == linea.startIndex)   // true

// Los indices se comparten con el padre y entre rebanadas
let campos = "a,b,c".split(separator: ",")      // [Substring]

// Convertir es lo que copia
let claveFinal = String(clave)

Un detalle que sorprende: el startIndex de un Substring no es cero ni equivale al principio del padre salvo que la rebanada empiece ahí. La rebanada hereda el sistema de coordenadas de la cadena original, lo que es exactamente lo que quieres para poder cruzar índices entre ambas, y exactamente lo que rompe el código escrito con la suposición de que toda colección empieza en su propio origen. Es el mismo malentendido que produce fallos con ArraySlice, y la cura es la misma: usa startIndex de la rebanada, nunca una constante.

El peligro de retener una rebanada

Aquí está el coste oculto del regalo. Como el Substring mantiene vivo el almacenamiento completo del padre, guardar una rebanada de diez caracteres extraída de un documento de cincuenta megabytes mantiene los cincuenta megabytes en memoria mientras esa rebanada exista. No es una fuga en sentido estricto, porque la memoria se libera cuando se libera la rebanada, pero se comporta como tal: el perfilador te muestra un consumo enorme y el objeto responsable es minúsculo.

func extraerTitulo(de documento: String) -> Substring {
  documento.prefix(while: { $0 != "\n" })   // retiene todo el documento
}

func extraerTituloSeguro(de documento: String) -> String {
  String(documento.prefix(while: { $0 != "\n" }))   // copia y libera
}

El caso más traicionero no es el de una función que devuelve una rebanada, porque ese se ve leyendo la firma, sino el de una estructura que la guarda de refilón. Un diccionario construido con rebanadas como claves, una caché de resultados de análisis, o un modelo que almacena el campo extraído de la línea original: en los tres casos el tipo del contenedor delata el problema, pero el contenedor suele estar declarado lejos del sitio donde se hizo el corte.

// Cada clave mantiene viva la linea completa de la que salio
var indice: [Substring: Int] = [:]

for (n, linea) in documento.split(separator: "\n").enumerated() {
  let clave = linea.prefix(while: { $0 != ":" })
  indice[clave] = n            // el documento entero queda retenido
}

// Copiar en la frontera del contenedor lo resuelve
var indiceSeguro: [String: Int] = [:]
for (n, linea) in documento.split(separator: "\n").enumerated() {
  indiceSeguro[String(linea.prefix(while: { $0 != ":" }))] = n
}

La regla que resuelve el noventa por ciento de los casos cabe en una frase: si la rebanada va a sobrevivir al ámbito donde se creó, conviértela; si va a morir antes que el padre, no la conviertas. Todo el trabajo intermedio de un analizador, de un tokenizador o de un filtro puede y debe hacerse con rebanadas, porque su vida es corta y encadenar cortes sin copiar es justamente lo que hace que ese trabajo sea rápido. Lo que se guarda en un modelo, en una caché o en una propiedad de larga vida se guarda como String.