Claves y valores

La regla oficial cabe en una línea: cualquier valor de Lua puede ser clave de una tabla salvo nil y salvo el no-número. Esa frase, aparentemente liberal, esconde tres precisiones con consecuencias diarias: los flotantes cuyo valor es entero se normalizan antes de indexar, las tablas y funciones se comparan por identidad y nunca por contenido, y asignar el valor ausente equivale a borrar la entrada. Quien no interioriza estas tres cosas escribe cachés que nunca aciertan y bucles que ven claves fantasma.

Qué puede ser una clave

Los seis tipos con valores utilizables como clave son booleano, número, cadena, función, tabla y dato de usuario. Los dos excluidos lo están por razones distintas y ambas instructivas:

local t = {}
t[true]      = "booleano"
t[42]        = "entero"
t["texto"]   = "cadena"
t[print]     = "funcion"
t[{}]        = "tabla anonima e inalcanzable"

t[nil] = 1        --> error: table index is nil
t[0/0] = 1        --> error: table index is NaN

nil no puede ser clave porque en Lua ausencia de valor y ausencia de entrada son la misma cosa: si t[nil] pudiera almacenarse, no habría forma de distinguir una clave presente de una consulta a una clave inexistente, y el recorrido con next perdería su condición de parada. El no-número queda fuera por un motivo más profundo: el estándar de coma flotante establece que no es igual a sí mismo, de modo que jamás podrías recuperar lo que guardaras bajo él. Una clave irrecuperable no es una clave; es una fuga de memoria con sintaxis de índice.

flowchart TD
V[Un valor cualquiera] --> P[Ausente o no numero]
P --> E[Prohibido como clave]
V --> Q[Flotante con parte decimal nula]
Q --> N[Se normaliza al entero equivalente]
V --> D[Tabla funcion o dato de usuario]
D --> I[Se compara por identidad de referencia]
V --> C[Booleano entero o cadena]
C --> W[Se compara por valor]

La normalización de las claves numéricas

Desde la versión 5.3 Lua distingue enteros de flotantes, pero al indexar una tabla aplica una regla de normalización: si la clave es un flotante cuyo valor es exactamente entero, se convierte al entero correspondiente antes de buscar. Es la única conversión implícita que sobrevive en el operador de indexación:

local t = {}
t[1]   = "uno"
print(t[1.0])   --> uno      (1.0 se normaliza a 1)

t[2.5] = "dos y medio"
print(t[2.5])   --> dos y medio   (no es entero: sigue siendo flotante)

La normalización opera únicamente sobre la clave, nunca sobre el valor almacenado, y no tiene contrapartida en el sentido inverso: el entero y el flotante siguen siendo valores de subtipos distintos si los guardas, y el resultado de math.type lo delata. Solo al indexar se unifican.

local t = {}
t[3] = "entero"
for k in pairs(t) do print(math.type(k)) end   --> integer, no float

Esta normalización es la que permite que un array construido con literales enteros siga funcionando cuando el índice viene de una división. Pero deja intacta la trampa clásica: un valor con parte decimal no nula es una clave distinta de cualquier entero, y no hay redondeo alguno. Tampoco hay conversión entre números y cadenas: t[1] y t["1"] son dos entradas independientes que pueden coexistir con valores distintos, algo que sorprende a quien llega de lenguajes donde los índices se convierten a texto.

La identidad como clave

Cuando la clave es una tabla, una función o un dato de usuario, Lua compara por referencia: dos valores son la misma clave si y solo si son el mismo objeto en memoria. Dos tablas con idéntico contenido son claves distintas, para siempre.

local a, b = {}, {}
local reg = {}
reg[a] = "primera"
reg[b] = "segunda"
print(reg[a], reg[b])   --> primera   segunda   (dos claves distintas)

local mismo = a
print(reg[mismo])       --> primera             (misma identidad)

Las cadenas son la excepción interesante a esta regla. Aunque son valores compuestos por dentro, Lua las interna: dos cadenas con el mismo contenido son literalmente el mismo objeto en memoria, de modo que compararlas cuesta lo mismo que comparar dos punteros y usarlas como clave es tan barato como usar un entero. Esa decisión es la que hace viable que todo el acceso a campos con nombre del lenguaje —cada t.campo, cada llamada a método, cada consulta al entorno global— pase por la parte dispersa de una tabla sin que el coste se note.

local x = "hola"
local y = "ho" .. "la"
local reg2 = {}
reg2[x] = 1
print(reg2[y])   --> 1   (misma cadena internada, misma clave)

El valor ausente borra

La asimetría más importante del modelo es que un valor ausente no puede ser clave pero sí puede ser valor, y cuando lo es su efecto no es almacenar nada: es eliminar la entrada.

local t = { a = 1, b = 2 }
t.a = nil                 -- no guarda nil: borra la clave "a"
print(t.a)                --> nil   (indistinguible de una clave que nunca existio)

Cuando el dominio del problema necesita distinguir no informado de informado como vacío, la solución idiomática es fabricar un centinela: una tabla vacía única, creada una sola vez, que signifique vacío deliberado y que se compare por identidad.

local VACIO = setmetatable({}, { __tostring = function() return "VACIO" end })

local registro = { nombre = "ana", telefono = VACIO }
if registro.telefono == VACIO then print("declarado sin telefono") end
if registro.correo == nil    then print("campo nunca informado") end

De ahí se sigue que en Lua no hay forma de preguntar si una clave existe con valor ausente, porque tal estado no es representable. Y de ahí se sigue también la prohibición de modificar una tabla mientras se recorre con pairs: añadir claves durante la iteración tiene comportamiento indefinido, mientras que asignar el valor ausente a una clave ya visitada está expresamente permitido, justo porque borrar no reorganiza la estructura interna.