From 8a7903f9068aba3beea38574b89868200f5a0300 Mon Sep 17 00:00:00 2001 From: Junseo Yoo Date: Wed, 26 Jun 2024 08:44:28 -0700 Subject: [PATCH] Added a section about type function type checking as one of future works --- docs/user-defined-type-functions.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/docs/user-defined-type-functions.md b/docs/user-defined-type-functions.md index 7dec5cf..890ccd0 100644 --- a/docs/user-defined-type-functions.md +++ b/docs/user-defined-type-functions.md @@ -134,4 +134,8 @@ In some sense, this design could be considered "cleaner" than introducing an ent ### More Builtin Type Functions -Another alternative is to simply let go of this idea and create more built-in type functions that cover a wider range of common use cases. This approach clearly lacks the flexibility of fully user-defined type functions because type manipulation would be limited to the predefined set of type functions designed by the Luau team. Furthermore, continuously expanding the set of built-in type functions could lead to bloat and complexity within the core language, making it harder to maintain. \ No newline at end of file +Another alternative is to simply let go of this idea and create more built-in type functions that cover a wider range of common use cases. This approach clearly lacks the flexibility of fully user-defined type functions because type manipulation would be limited to the predefined set of type functions designed by the Luau team. Furthermore, continuously expanding the set of built-in type functions could lead to bloat and complexity within the core language, making it harder to maintain. + +### Type Function Type Checking + +In the future, we could investigate adding type checking to user defined type functions. In Haskell's type families, this is done with _kinds_ (aka types of types). Similarly, we could look into introducing kinds to Luau, but for the purpose of this RFC, this feature will be left for future works. \ No newline at end of file