Structures vs tables libres

Tu as maintenant deux façons de travailler avec des tables d’enregistrements : la méthode libre que tu as toujours utilisée en Lua, et les formes déclarées. Il vaut la peine de s’arrêter un instant pour voir ce que chacune t’apporte.

Une table libre accepte tout. Cette flexibilité a un prix : si tu orthographies mal un champ (user.nmae), tu obtiens silencieusement nil ; si tu oublies un champ, le bogue apparaît bien plus tard, à l’exécution, dans le premier code qui touche à cette entrée manquante :

local user = {name = "Ana", age = 20}
print(user.nmae) -- table non stricte : affiche nil sans avertissement

Déclare une forme et ces erreurs passent de l’exécution au moment de l’édition. Le vérificateur signale la faute de frappe dès que tu l’écris, ton éditeur peut compléter automatiquement les noms de champs, et la déclaration type sert aussi de documentation sur le contenu de la table :

type User = {name: string, age: number}
local user: User = {name = "Ana", age = 20}
print(user.nmae) -- ✗ erreur de type : clé 'nmae' introuvable dans User

Si tu viens de TypeScript, note que Luau n’a pas de mot-clé interface : type permet de décrire toutes les formes. Il n’y a pas non plus de « fusion des déclarations » : déclarer deux types portant le même nom dans la même portée est une erreur, donc chaque forme a exactement une définition.

Les formes de Luau sont structurelles : toute table contenant les bons champs avec les bons types correspond, quel que soit l’endroit ou la manière dont elle a été créée. Les tables libres ont aussi leur utilité : les scripts rapides et les données véritablement dynamiques n’ont pas besoin d’une forme déclarée. Toutefois, pour tout ce qui est transmis entre des fonctions, une forme permet de détecter les erreurs tant qu’elles sont encore faciles à corriger.