Shapes vs. Loose Tables

You now have two ways to work with record tables: the loose way you've always used in Lua, and declared shapes. It's worth pausing to see what each buys you.

A loose table accepts anything. That flexibility has a price: misspell a field (user.nmae) and you silently get nil; forget a field and the bug surfaces far away, at runtime, in whatever code first touches the hole:

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

Declare a shape and those mistakes move from runtime to edit time. The checker flags the typo the moment you write it, your editor can autocomplete field names, and the type declaration doubles as documentation of what the table contains:

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

If you're coming from TypeScript, note that Luau has no interface keyword — type handles every shape. There's also no "declaration merging": declaring two types with the same name in the same scope is an error, so each shape has exactly one definition.

Luau's shapes are structural: any table with the right fields of the right types matches, no matter where or how it was created. And loose tables still have their place — quick scripts and truly dynamic data don't need a declared shape. For anything passed between functions, though, a shape catches mistakes while they're still cheap.