Structures vs tables libres

Vous disposez désormais de deux façons de travailler avec les tables d'enregistrements : la méthode loose que vous avez toujours utilisée dans Luau, et les formes déclarées (shapes). Il vaut la peine de s'arrêter pour voir ce que chacune vous apporte.

Une table flexible (loose) accepte n'importe quoi. Cette flexibilité a un prix : faîtes une faute de frappe dans un champ (user.nmae) et vous obtenez nil en silence ; oubliez un champ et le bug apparaîtra bien plus loin, à l'exécution, dans le premier code qui touchera à ce vide :

local user = {name = "Ana", age = 20}
print(user.nmae) -- loose table: silently prints nil

Déclarez une forme et ces erreurs passent du moment de l'exécution au moment de l'édition. Le vérificateur de type signale la faute de frappe dès que vous l'écrivez, votre éditeur peut autocompléter les noms de champs, et la déclaration type sert également de documentation sur ce que contient la table :

type User = {name: string, age: number}
local user: User = {name = "Ana", age = 20}
print(user.nmae) -- ✗ type error: key 'nmae' not found in User

Si vous venez de TypeScript, notez que Luau n'a pas de mot-clé interface — type gère toutes les formes. Il n'y a pas non plus de "fusion de déclarations" (declaration merging) : déclarer deux types avec le même nom dans la même portée est une erreur, donc chaque forme a exactement une seule définition.

Les formes de Luau sont structurelles : n'importe quelle table possédant les bons champs avec les bons types correspond, peu importe où ou comment elle a été créée. Et les tables flexibles (loose) ont toujours leur utilité — les scripts rapides et les données vraiment dynamiques n'ont pas besoin d'une forme déclarée. Cependant, pour tout ce qui est transmis entre des fonctions, une forme permet de capturer les erreurs pendant qu'elles sont encore faciles et peu coûteuses à corriger.