Propiedades de extensión y receptores nulables

Kotlin permite escribir val List<T>.penultimo: T y usarlo como si la lista guardara ese dato en algún sitio. No lo guarda, ni podría: la instancia ya está construida, su tamaño en memoria es fijo y ninguna función estática declarada fuera va a hacerla crecer. Una propiedad de extensión es exactamente un get() con la sintaxis de un campo, y toda la discusión sobre cuándo usarlas gira en torno a esa mentira consentida. La sintaxis de propiedad promete al lector algo muy concreto —esto ya está ahí, leerlo es barato y leerlo dos veces da lo mismo— y quien escribe la extensión decide si esa promesa se cumple. Cuando se cumple, el código gana un sustantivo donde antes había un verbo. Cuando no, se convierte en una trampa que ni el compilador ni el perfilador señalan.

Sin campo de respaldo: solo accesores

La declaración obliga a dar un get(), y por eso la forma de una sola línea con = no vale. El compilador lo dice sin rodeos.

val <T> List<T>.penultimo: T
    get() = this[size - 2]

val String.primeraLetra: Char
    get() = this[0]

// Error: extension property cannot be initialized because it has no backing field
val String.contador: Int = 0

Lo que se genera es un método estático getPenultimo(List), sin ningún campo asociado. Las propiedades de extensión mutables son posibles, pero solo cuando el estado vive ya en otro sitio y el accesor se limita a redirigirlo:

var StringBuilder.ultimaLetra: Char
    get() = this[length - 1]
    set(valor) { this.setCharAt(length - 1, valor) }

Aquí no hay estado nuevo: el set traduce una asignación a una llamada sobre la API pública del receptor. Esa es la única forma legítima de un var de extensión. Si alguna vez necesitas asociar datos nuevos a instancias ajenas, la extensión no es el mecanismo; hará falta un mapa externo con claves débiles, un envoltorio o un delegado, y las tres opciones tienen un coste que conviene decidir a la vista.

flowchart LR
prop[val String.primeraLetra] --> gen[metodo estatico getPrimeraLetra]
gen --> arg[recibe el receptor como parametro]
gen --> nofield[no existe ningun campo asociado]
nofield --> conc[cada lectura ejecuta el cuerpo entero]

Cuándo aporta y cuándo confunde

La regla útil no es sintáctica sino semántica, y se puede formular como tres condiciones que deben cumplirse a la vez. La propiedad debe ser barata, del orden de unas pocas operaciones y sin trabajo proporcional al tamaño del receptor. Debe ser idempotente, de modo que dos lecturas seguidas devuelvan lo mismo si nadie ha tocado el objeto. Y debe ser libre de efectos: leerla no puede abrir un archivo, tocar la red, escribir en un registro ni mutar nada.

La biblioteca estándar es coherente con este criterio y sirve de calibrador. CharSequence.indices y CharSequence.lastIndex son propiedades porque son aritmética sobre length. String.reversed() y Iterable.sorted() son funciones porque construyen una estructura nueva. Iterable.count() es función aunque a veces sea constante, precisamente porque en el caso general no lo es.

Un contraste que se ve muy bien con Sequence, donde la pereza vuelve el error especialmente caro:

// Mal: forma de propiedad, coste lineal y consumo de la secuencia
val <T> Sequence<T>.tamano: Int
    get() = count()

// Bien: la forma de funcion avisa de que ahi se hace trabajo
fun <T> Sequence<T>.tamano(): Int = count()

Leer secuencia.tamano dos veces no solo cuesta dos recorridos: si la secuencia es de un solo uso, la segunda lectura lanza una excepción. Ninguna de esas dos cosas encaja con lo que un lector espera al ver la sintaxis de campo.

Receptores nulables: el truco de la llamada sobre null

Como el receptor es un parámetro, nada impide declararlo con tipo nulable. Y como es un parámetro, pasarle null no produce ninguna desreferencia: dentro del cuerpo, this simplemente vale null y hay que comprobarlo.

fun String?.oVacio(): String = this ?: ""

val String?.estaVacioONulo: Boolean
    get() = this == null || this.isEmpty()

fun main() {
    val nombre: String? = null
    println(nombre.oVacio())          // cadena vacia, sin llamada segura
    println(nombre.estaVacioONulo)    // true
}

Esa llamada sin ?. sobre una variable nulable es legal y no lanza nada, porque se compila como oVacio(nombre). Es el mismo mecanismo por el que null.toString() devuelve la cadena null en lugar de fallar: la biblioteca estándar declara Any?.toString() con receptor nulable. También es de donde vienen isNullOrBlank e isNullOrEmpty, cuya gracia entera está en absorber el caso nulo dentro del contrato.

Dentro del cuerpo, el compilador trata this como un valor nulable normal, con todo el aparato de contracción de tipos disponible. Después de una comprobación, el receptor queda contraído al tipo no nulable y se puede usar sin ceremonia:

fun String?.longitudSegura(): Int {
    if (this == null) return 0
    return length          // aqui this ya es String, no String?
}

Y con @OptIn a los contratos de la biblioteca estándar, una función como isNullOrEmpty propaga esa información al llamador: tras un if (texto.isNullOrEmpty()) return, el compilador sabe que texto no es nulo en el resto del bloque. Esa cooperación entre extensión y análisis de flujo es una de las cosas mejor resueltas del lenguaje, y solo es posible porque el receptor era un parámetro desde el principio.