El principio: implementar un nombre, no sobrecargar un símbolo

Hay una diferencia conceptual entre lo que hace Kotlin y lo que casi todo el mundo cree que hace cuando escribe una suma sobre un tipo propio. La creencia habitual, heredada de C++, es que el lenguaje permite dar un significado nuevo a un símbolo, como si el símbolo fuese una entidad declarable bajo la cual uno registra comportamientos. Kotlin no ofrece nada de eso. Cada símbolo es sintaxis fija del analizador, con una precedencia fija, una asociatividad fija y una traducción fija hacia una llamada a una función cuyo nombre elige el lenguaje y no tú. Lo único que aporta el programador es la implementación de esa función, sobre el tipo que quiera, con el modificador operator como declaración explícita de que sabe que está participando en una convención. Toda la potencia y todos los límites de este nivel salen de esa inversión de responsabilidades: no se extiende la gramática, se completa un protocolo de nombres que la gramática ya conoce de antemano.

Un símbolo es azúcar de una llamada con nombre fijo

La regla operativa cabe en una frase: al ver una notación de operador, el compilador la reescribe como una llamada a un miembro o a una extensión con un nombre predeterminado, y después resuelve esa llamada con las reglas ordinarias de resolución de sobrecargas. No hay ninguna tabla de símbolos definibles ni ningún registro global; hay una reescritura y, a partir de ahí, código normal.

data class Vec2(val x: Double, val y: Double)

operator fun Vec2.plus(otro: Vec2) = Vec2(x + otro.x, y + otro.y)
operator fun Vec2.times(k: Double) = Vec2(x * k, y * k)
operator fun Double.times(v: Vec2) = v * this   // la otra mano, explícita

// lo que escribes
val destino = posicion + velocidad * dt
// lo que el compilador entiende
val destinoBis = posicion.plus(velocidad.times(dt))

Conviene notar dos cosas de ese ejemplo. La primera es que la precedencia del producto sobre la suma no la aporta nadie de los tipos implicados: viene de la gramática y se aplica antes de saber siquiera qué tipos hay. La segunda es que la conmutatividad no es gratis. El símbolo del producto se traduce siempre a una llamada cuyo receptor es el operando izquierdo, de modo que si quieres escribir el escalar a la izquierda debes declarar una segunda función sobre Double. El lenguaje no deduce nada del álgebra: obedece a la letra.

La resolución posterior es la habitual, con la consecuencia práctica de que los operadores se sobrecargan por tipo de parámetro exactamente igual que cualquier otra función, y de que un miembro gana a una extensión cuando ambos son aplicables.

class Dinero(val centimos: Long) {
    operator fun plus(otro: Dinero) = Dinero(centimos + otro.centimos)
    operator fun times(veces: Int) = Dinero(centimos * veces)
}

La tabla de correspondencias

Merece la pena leer esa tabla como lo que es: la lista completa y cerrada de puntos de extensión sintáctica del lenguaje. No hay más, y ninguno de ellos admite negociación sobre el nombre. Un tipo que quiera comportarse como un número, como una colección, como una función o como una tupla lo hace implementando exactamente esos nombres, ni uno más.

Qué comprueba el compilador y qué no

El modificador operator no es decorativo ni opcional. Su ausencia sobre una función con nombre convenido hace que la notación no compile, y su presencia activa un conjunto de comprobaciones estructurales que dependen del nombre concreto.

class Caja(val n: Int) {
    fun plus(otra: Caja) = Caja(n + otra.n)      // función normal
}
// Caja(1) + Caja(2)   error: operator modifier is required

class Marcador {
    operator fun compareTo(otro: Marcador): Boolean = true    // error: debe devolver Int
    operator fun unaryMinus(x: Int) = x                       // error: no admite parámetros
}

La comprobación es puramente estructural: nombre correcto, aridad correcta y, cuando la traducción lo necesita, tipo de retorno correcto. Nada más. El compilador no verifica en ningún momento que tu plus sea asociativo, que tu compareTo defina un orden total, que tu equals sea simétrico ni que tu get termine. Toda la parte que un lector va a dar por supuesta al leer un símbolo queda enteramente bajo tu responsabilidad, y ese desfase entre lo comprobado y lo esperado es el material de las tres lecciones siguientes.

Hay dos detalles de herencia que conviene fijar ahora. El primero es que la propiedad de ser operador se hereda: al sobrescribir un miembro que ya era operator, la implementación no necesita repetir el modificador, y por eso equals se escribe con override a secas. El segundo es que se puede declarar como extensión, lo que convierte a este mecanismo en la vía canónica para dar notación de operador a tipos que no controlas.

No hay operadores nuevos, y eso es la mitad del diseño

flowchart TD
A[Expresion con simbolo] --> B[La gramatica fija precedencia y asociatividad]
B --> C[Reescritura al nombre convenido]
C --> D{Existe miembro o extension con ese nombre}
D -- No --> E[Error de compilacion]
D -- Si --> F{Lleva el modificador operator}
F -- No --> E
F -- Si --> G{Aridad y tipo de retorno validos}
G -- No --> E
G -- Si --> H[Llamada ordinaria resuelta por sobrecarga]

No se puede declarar un símbolo que el lenguaje no tenga, ni cambiar la precedencia de uno existente, ni volver asociativo por la derecha algo que la gramática hace por la izquierda. Esa clausura es deliberada: si la precedencia dependiera de las bibliotecas importadas, leer una expresión exigiría conocer todas las declaraciones visibles, y ninguna herramienta podría analizar un archivo antes de resolverlo entero. Kotlin prefiere que la forma de una expresión se entienda antes que su significado.

Para las operaciones que merecen notación pero no símbolo existe una salida distinta y honesta: la función infix, que se escribe sin puntos ni paréntesis, tiene una única precedencia propia por debajo de los operadores aritméticos y nunca se confunde con ellos.

infix fun Vec2.proyectadoSobre(eje: Vec2): Vec2 = eje * ((this dot eje) / (eje dot eje))
infix fun Vec2.dot(otro: Vec2): Double = x * otro.x + y * otro.y

La ganancia de esa forma es que conserva el nombre de la operación en el sitio de llamada, que es justo lo que un símbolo elimina. Cuando dudes entre inventar un uso para un símbolo existente y escribir una función infija, la infija gana casi siempre, porque no pide al lector que adivine nada.