RFC: Exact Table Types #624
Conversation
There was a problem hiding this comment.
From first read, looks like this solves #455, if I'm not mistaken. If so, major +1.
Double +1 for making exact the default as well.
| mitigate problems. Since Luau currently only has sealed, inexact table types we can start by adding | ||
| the syntax for explicit inexact tables (e.g. `{x: number, y: number, ...}`) and implement a warning | ||
| that explains the default behavior will change in the future and to change it to the explicit | ||
| inexact syntax if the programmer would like to keep the current behavior. At a later date, we can | ||
| enable exact-by-default, but should provide an explicit suggestion in the error message to tell the | ||
| programmer that if they _intended_ to allow tables with additional properties, they can change the | ||
| signature of the function to include the `...`. |
There was a problem hiding this comment.
Maybe the discussion about how inexact tables will work should be more prominent than just a section inside "Drawbacks", or is this intended to go in a different RFC? It feels like an important point, especially migration
e.g., Personally, I have no particular opinion, but were alternatives in syntax considered (such as TypeScript's interface { })
There was a problem hiding this comment.
There is (admittedly brief) mention in the design section about the syntax of inexact tables. Is there something you're concerned isn't discussed? I can, at minimum, say explicitly that the behavior of inexact tables defined using the proposed inexact syntax would be the same as the current behavior (i.e. they support the width subtyping already accepted and implemented in #38.)
There was a problem hiding this comment.
Ah yeah, I see it now - I must have missed it earlier.
No particular issue for me, just a note that it is very likely to get comments down the road from users about "why was XYZ not chosen", especially for syntax - but this is more of a nitpicking comment
aatxe
force-pushed
the
exact-table-types
branch
from
b3b13b9 to
c6dc391
Compare
|
This PR is closed as part of RFC migration; please see #1074 (comment) for context. Additional notes: I don't fully know if this is still on the table given where we are at with other advances in the type system... it does feel like this may cover a significant gap between our users' perception of what types do, and what they actually do right now. |
|
I think this is still on the table. I'm less optimistic now than I was at the time about the syntactic migration (to exact by default), but I do think there's considerable value in that. Even if we don't, it seems like having support for table types without width subtyping is broadly desirable and something we want to support. Additionally, the ongoing work on the new type inference engine is already helping to clear up the muddied waters with unsealed tables since we have put in the work to truly make them an inference detail and not directly manifest to users. So, we're essentially freeing up complexity budget around table types right now. |
Rendered