From 0f22c19a7adb3ff355f0139d14b9335d9306d3e1 Mon Sep 17 00:00:00 2001 From: aaron Date: Wed, 28 Aug 2024 13:21:15 -0700 Subject: [PATCH] Add a small paragraph clarifying the scoping and shadowing rules being the same as type aliases --- docs/user-defined-type-functions.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/user-defined-type-functions.md b/docs/user-defined-type-functions.md index e8cfeb9..f85a3aa 100644 --- a/docs/user-defined-type-functions.md +++ b/docs/user-defined-type-functions.md @@ -52,6 +52,8 @@ type ty = rawget -- resolves to `ty` defined as `string` This function takes `tbl`, a table type, and `key`, the type of a property key for the table (typically a string singleton type), and computes the corresponding value type for the property `key` in the table `tbl`. If `tbl` is not a table type, or `key` is not found in `tbl`, then the function raises an error. +The scoping and shadowing rules of user-defined type functions will be made to match the existing rules for type aliases (i.e. `type Array = {T}`) which are, as it turns out, a sort of total form of type functions in the first place. This means that they are order-independent, and can refer to one another, as well as to type aliases. We do not intend to introduce an additional set of scoping rules, so ensuring they work the same as type aliases already do is a requirement for the design. + ### The type runtime To understand how type functions behave, we have to consider a split between stages: type analysis time and runtime. The full types of Luau's type system currently exist only during type analysis, and never during runtime. This RFC proposes changing Luau to include an additional stage, type runtime, that is part of the overall type analysis. During type analysis, when we encounter a user-defined type function, e.g. `rawget<...>` in the example above, we will serialize the type parameters of that call into a form that Luau can manipulate, and then execute the body of the type function in a Luau VM (this stage would be the "type runtime"), and reify its results (returning a value, erroring, etc.) back into type analysis. This means that the type solver will need to maintain a VM instance for evaluating user-defined type functions, and that each reference to a type function corresponds to evaluating a function call in that VM.