RFC: Exact Table Types

[aatxe]

Rendered

Migrated from luau-lang/luau#624.

[vegorov-rbx]

What will be the mechanism for the warnings?
Usually it means the linter, but I'm not sure it's powerful enough to find this kind of issue.

[aatxe]

What will be the mechanism for the warnings? Usually it means the linter, but I'm not sure it's powerful enough to find this kind of issue.

It might require making the linter more type-aware, which is perhaps more work than I had anticipated it being when I first wrote this.

[karl-police]

This RFC is interesting though, and pursues something I pursued, with setting sealed tables and unsealed tables.

[alexmccord]

One more use case for this: iterator of some inexact tables results in ...unknown

function f(t: { p: string })
  for i, v in t do -- i : unknown, v : unknown
  end
end

f({ p = "a", q = 7 }) -- q : number is reachable to the iterator, so v : string does not hold

[karl-police]

Other use case is to support Module stuff e.g. react-lua

If you create a custom extended property, you'll notice that everyone says that if you do use require, all tables become unmutable... though... you see the issue e.g. when you want props to be custom and mutable (for the autocomplete).

[karl-police]

I really wanted to figure out what happens in the new solver right now. That I wanted to test it.

The result is actually cool, because it seems to be working.

the issue

I used a Free Table Type, it has the exact same bugs. I don't think free table types are meant to be used at that point, not sure

[karl-police]

if you do this

local test = typeof({}) & typeof({})

it actually creates an Intersection and the ConstraintSolver will skip it hence why the autocomplete never knows. Which seems to be intended.

Free Types are an exception but they break somehow.

Aslong the tables aren't put into one type, I don't really know if this would work.