Rangos y destructuring: rangeTo, componentN y el buen gusto

Quedan por cubrir dos convenciones que completan el catálogo y que tienen algo en común: ninguna de las dos hace lo que su apariencia sugiere. Los dos puntos no describen un intervalo abstracto sino que construyen un objeto concreto mediante una llamada, con su tipo, su coste y sus operaciones; y el desestructurado no reparte campos por nombre sino que invoca funciones numeradas cuya correspondencia con las propiedades es puramente posicional. Entender ambas cosas literalmente evita dos clases de error muy distintas y prepara el terreno para la única pregunta que queda por responder en este nivel, que no es técnica sino de criterio. Después de cinco lecciones sabiendo exactamente qué se puede hacer, corresponde decidir qué conviene hacer, y ese juicio tiene un solo destinatario: quien lea el código sin haber leído la implementación.

Los dos puntos construyen un objeto

La notación de rango cerrado se traduce a rangeTo y la de rango abierto por la derecha a rangeUntil. La librería estándar las declara como extensiones genéricas sobre cualquier tipo comparable, y por eso funcionan sobre fechas, versiones o cadenas sin que nadie haya escrito nada específico para ellas.

// firmas de la libreria estandar, simplificadas
public operator fun <T : Comparable<T>> T.rangeTo(that: T): ClosedRange<T>
public operator fun <T : Comparable<T>> T.rangeUntil(that: T): OpenEndRange<T>

val temporada = inicio..fin                 // inicio.rangeTo(fin)
val jornada = apertura..<cierre             // apertura.rangeUntil(cierre)

Un rango así construido responde a la pertenencia porque su contains está definido en términos de compareTo, lo que enlaza directamente con el contrato de orden de la tercera lección: si tu comparación no es coherente, tus rangos mienten. En cambio no responde al recorrido, porque para eso hace falta la convención iterator, y entre dos fechas comparables no existe ninguna noción canónica de paso siguiente que la librería pueda suponer. Los rangos numéricos sí son recorribles porque sus tipos concretos implementan además la interfaz de iteración, y ahí el compilador aplica una optimización que conviene conocer: cuando los extremos son primitivos y el rango se usa directamente en una condición o en la cabecera de un bucle, no se construye ningún objeto y se generan comparaciones y un contador.

class Temporada(val desde: Fecha, val hasta: Fecha) : ClosedRange<Fecha> {
    override val start get() = desde
    override val endInclusive get() = hasta
    infix fun solapaCon(otra: Temporada) = desde <= otra.hasta && otra.desde <= hasta
}

operator fun Fecha.rangeTo(otra: Fecha) = Temporada(this, otra)

val alta = junio..septiembre
val cruce = alta solapaCon vacaciones

Ese ejemplo enseña de paso una jerarquía de decisiones que se repite: el intervalo merece el operador porque los dos puntos ya significaban eso, y el solapamiento merece una función infija porque no existe ningún símbolo que todo el mundo asocie con esa idea. Mezclar ambos registros en el mismo tipo no es una incoherencia, es exactamente el criterio bien aplicado.

Lo que parece un operador y no lo es

Tres notaciones muy usadas en los rangos numéricos no son operadores en absoluto: son funciones infijas ordinarias, sin ninguna traducción especial y sin ningún privilegio gramatical. La diferencia es visible en cuanto se mezclan con aritmética, porque toda función infija tiene una única precedencia común, situada por debajo de la de los operadores.

for (i in 10 downTo 1) { }          // funcion infija
for (i in 0 until n step 2) { }     // dos funciones infijas encadenadas
val r = 0..n - 1                    // el operador tiene mas precedencia que la resta

Esa asimetría explica por qué la primera y la tercera línea se leen distinto de lo que uno espera si las considera equivalentes. Y explica también una recomendación práctica de la librería estándar: la forma con la notación abierta por la derecha es preferible a la función infija equivalente, porque siendo operador conserva la precedencia esperada y admite tipos que no son enteros.

componentN: la convención sin símbolo

El desestructurado no tiene símbolo propio, pero funciona exactamente igual que el resto: una declaración con varios nombres se traduce en llamadas a funciones numeradas, tantas como nombres haya, en el orden en que están escritos.

data class Medida(val valor: Double, val unidad: String)

val (v, u) = medida
// val v = medida.component1()
// val u = medida.component2()

for ((clave, dato) in mapa) { }     // component1 y component2 sobre la entrada
lista.forEach { (v, u) -> registrar(v, u) }

La clase de datos genera esas funciones a partir de las propiedades del constructor primario y en su mismo orden, que es la fuente de la fragilidad que ya estudiamos: reordenar dos propiedades del mismo tipo compila sin una sola advertencia en el sitio de la declaración y cambia el significado de todos los desestructurados del proyecto. El desestructurado por nombre que Kotlin 2.3.20 introdujo desactiva esa trampa emparejando por identificador, y reserva la forma con corchetes para los tipos donde la posición sí es la información. La convención numerada sigue existiendo debajo, y sigue siendo la única vía cuando el tipo no es tuyo.

operator fun java.time.LocalDate.component1() = year
operator fun java.time.LocalDate.component2() = monthValue
operator fun java.time.LocalDate.component3() = dayOfMonth

val (anio, mes, dia) = fecha

Ese es el uso más sano de la convención: dar reparto posicional a un tipo ajeno cuyos componentes tienen un orden universalmente aceptado. Cuando el orden no es evidente para todo el mundo, tres nombres numerados son una invitación a equivocarse, y por eso conviene no pasar de dos o tres componentes y no ofrecerlos nunca sobre tipos cuyos campos podrían reordenarse.

Dos detalles finales completan el mecanismo. El guion bajo omite un componente y, además, evita la llamada correspondiente, de modo que saltarse una posición cuyo cálculo sea caro no cuesta nada. Y en una lambda, unos nombres entre paréntesis no declaran varios parámetros sino uno solo que se desestructura, distinción que produce errores desconcertantes cuando se confunden ambas formas.

val (_, unidad) = medida            // component1 no llega a llamarse

lista.map { (v, u) -> "$v $u" }     // un parametro desestructurado
lista.map { v, u -> "" }            // error: la lambda no tiene dos parametros

Diseñar operadores que no sorprendan

flowchart TD
A[Quiero notacion de operador para esta operacion] --> B{El simbolo ya significa esto en todas partes}
B -- No --> N[Funcion con nombre o funcion infija]
B -- Si --> C{La operacion es barata y total}
C -- No --> N
C -- Si --> D{Respeta las leyes que el lector supondra}
D -- No --> N
D -- Si --> E{El resultado se lee sin abrir la implementacion}
E -- No --> N
E -- Si --> F[Operador justificado]

Queda una comprobación final que resume las anteriores y que conviene hacer siempre en voz alta. Lee la expresión que has habilitado como si no supieras nada del proyecto y pregúntate qué crees que hace. Si tu respuesta coincide con lo que hace, el operador está bien elegido. Si tu respuesta necesita una condición previa del tipo de si esto es una lista mutable entonces, el operador está mal elegido y una función con nombre lo habría dicho todo en una palabra. Es un criterio poco sofisticado y no se equivoca casi nunca.