From 0faf7b95124e85dcaaad0bed1eecfbdcd482ca00 Mon Sep 17 00:00:00 2001 From: DavidLoveLuau Date: Tue, 10 Mar 2026 17:46:41 +0300 Subject: [PATCH 1/8] Add files via upload --- Type Functions Parameter Names Rfc | 100 +++++++++++++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 Type Functions Parameter Names Rfc diff --git a/Type Functions Parameter Names Rfc b/Type Functions Parameter Names Rfc new file mode 100644 index 00000000..2d604692 --- /dev/null +++ b/Type Functions Parameter Names Rfc @@ -0,0 +1,100 @@ +# Feature name: Parameter Names in types.newfunction + +## Summary +Add the ability to specify parameter names when dynamically constructing function types using the experimental `types.newfunction` API. This will improve code readability, developer experience (DX), and autocomplete integration in tooling such as Luau LSP and Roblox Studio. + +## Motivation +Currently, when a developer generates a custom function type using `types.newfunction(...)`, they can only define the types of the parameters, but not their names. + +Example of the current limitation: + +```luau +local dynamicFuncType = types.newfunction({ + parameters = { + head = { types.string, types.boolean } + }, + returns = { + head = { types.number } + } +}) +``` + +The resulting type is evaluated as `(string, boolean) -> number`. While functionally correct for type-checking, this significantly degrades the developer experience because users of this type lose context about what the `string` and `boolean` arguments actually represent. + +If we compare this to standard static Luau syntax: + +```luau +type MyFunc = (PlayerName: string, IsAdmin: boolean) -> number +``` + +The parameter names `PlayerName` and `IsAdmin` are preserved and heavily utilized by language servers to provide meaningful autocomplete tooltips and signature help. + +Developers increasingly rely on type functions to generate schemas for networking, ECS frameworks, and binary serialization wrappers. Allowing `types.newfunction` to attach names to parameters would bring dynamic type generation on par with static type definitions. + +## Design +We propose extending the configuration table accepted by `types.newfunction` to accommodate parameter names alongside parameter types. + +Based on the current API where `parameters` is an object containing a `head` array of types, here are the proposed approaches: + +### Option 1: Names property in `newfunction` +Add an optional `parameterNames` field to the configuration table. + +```luau +return types.newfunction({ + parameters = { + head = { types.string, types.boolean } + }, + parameterNames = { "PlayerId", "IsAdmin" }, + returns = { + head = { types.number } + } +}) +``` +The resulting type would be correctly evaluated and displayed by language servers as `(PlayerId: string, IsAdmin: boolean) -> number`. + +If the length of the `parameterNames` array does not match the arity of the `parameters.head` table, the type-checker should emit a type error during the type function evaluation to enforce correctness. + +### Option 2: Dict-like syntax in `head` +Allow the `head` array to optionally act as a dictionary where the keys act as the parameter names: + +```luau +return types.newfunction({ + parameters = { + head = { + Var1 = types.boolean, + Var2 = types.string + } + }, + returns = { + head = { types.number } + } +}) +``` +*Note:* Since Luau dictionary order is not guaranteed, this might require compiler-level stability guarantees for keys or could be problematic for strict positional arguments. + +### Option 3: Named parameters via Singletons +Use string singletons as keys in the `head` table to represent names: + +```luau +return types.newfunction({ + parameters = { + head = { + [types.singleton("Var1")] = types.boolean, + [types.singleton("Var2")] = types.string + } + }, + returns = { + head = { types.number } + } +}) +``` +*Note:* Similar to Option 2, this relies on dictionary key ordering which may not be deterministic. + +## Drawbacks +- Increases the complexity of the `types` library API. +- Parameter names in Luau function types do not affect type strictness or execution logic, meaning this change provides no behavioral benefit to the type-checker itself; it is purely a DX and tooling enhancement. +- Options 2 and 3 introduce dictionary keys into `head`, which traditionally expects an ordered array of types. Luau does not guarantee iteration order for non-array keys, which could lead to non-deterministic parameter orders unless specifically handled by the compiler. + +## Alternatives +### Do Nothing +Developers will continue to see anonymous `(type1, type2)` signatures in autocomplete for dynamically generated function types, forcing them to rely on external documentation or inline comments to understand the purpose of the arguments. From 2dc73743aa0cf0b21e660c5ea5d6ce0b4ab066a3 Mon Sep 17 00:00:00 2001 From: DavidLoveLuau Date: Tue, 10 Mar 2026 18:08:48 +0300 Subject: [PATCH 2/8] Delete Type Functions Parameter Names Rfc --- Type Functions Parameter Names Rfc | 100 ----------------------------- 1 file changed, 100 deletions(-) delete mode 100644 Type Functions Parameter Names Rfc diff --git a/Type Functions Parameter Names Rfc b/Type Functions Parameter Names Rfc deleted file mode 100644 index 2d604692..00000000 --- a/Type Functions Parameter Names Rfc +++ /dev/null @@ -1,100 +0,0 @@ -# Feature name: Parameter Names in types.newfunction - -## Summary -Add the ability to specify parameter names when dynamically constructing function types using the experimental `types.newfunction` API. This will improve code readability, developer experience (DX), and autocomplete integration in tooling such as Luau LSP and Roblox Studio. - -## Motivation -Currently, when a developer generates a custom function type using `types.newfunction(...)`, they can only define the types of the parameters, but not their names. - -Example of the current limitation: - -```luau -local dynamicFuncType = types.newfunction({ - parameters = { - head = { types.string, types.boolean } - }, - returns = { - head = { types.number } - } -}) -``` - -The resulting type is evaluated as `(string, boolean) -> number`. While functionally correct for type-checking, this significantly degrades the developer experience because users of this type lose context about what the `string` and `boolean` arguments actually represent. - -If we compare this to standard static Luau syntax: - -```luau -type MyFunc = (PlayerName: string, IsAdmin: boolean) -> number -``` - -The parameter names `PlayerName` and `IsAdmin` are preserved and heavily utilized by language servers to provide meaningful autocomplete tooltips and signature help. - -Developers increasingly rely on type functions to generate schemas for networking, ECS frameworks, and binary serialization wrappers. Allowing `types.newfunction` to attach names to parameters would bring dynamic type generation on par with static type definitions. - -## Design -We propose extending the configuration table accepted by `types.newfunction` to accommodate parameter names alongside parameter types. - -Based on the current API where `parameters` is an object containing a `head` array of types, here are the proposed approaches: - -### Option 1: Names property in `newfunction` -Add an optional `parameterNames` field to the configuration table. - -```luau -return types.newfunction({ - parameters = { - head = { types.string, types.boolean } - }, - parameterNames = { "PlayerId", "IsAdmin" }, - returns = { - head = { types.number } - } -}) -``` -The resulting type would be correctly evaluated and displayed by language servers as `(PlayerId: string, IsAdmin: boolean) -> number`. - -If the length of the `parameterNames` array does not match the arity of the `parameters.head` table, the type-checker should emit a type error during the type function evaluation to enforce correctness. - -### Option 2: Dict-like syntax in `head` -Allow the `head` array to optionally act as a dictionary where the keys act as the parameter names: - -```luau -return types.newfunction({ - parameters = { - head = { - Var1 = types.boolean, - Var2 = types.string - } - }, - returns = { - head = { types.number } - } -}) -``` -*Note:* Since Luau dictionary order is not guaranteed, this might require compiler-level stability guarantees for keys or could be problematic for strict positional arguments. - -### Option 3: Named parameters via Singletons -Use string singletons as keys in the `head` table to represent names: - -```luau -return types.newfunction({ - parameters = { - head = { - [types.singleton("Var1")] = types.boolean, - [types.singleton("Var2")] = types.string - } - }, - returns = { - head = { types.number } - } -}) -``` -*Note:* Similar to Option 2, this relies on dictionary key ordering which may not be deterministic. - -## Drawbacks -- Increases the complexity of the `types` library API. -- Parameter names in Luau function types do not affect type strictness or execution logic, meaning this change provides no behavioral benefit to the type-checker itself; it is purely a DX and tooling enhancement. -- Options 2 and 3 introduce dictionary keys into `head`, which traditionally expects an ordered array of types. Luau does not guarantee iteration order for non-array keys, which could lead to non-deterministic parameter orders unless specifically handled by the compiler. - -## Alternatives -### Do Nothing -Developers will continue to see anonymous `(type1, type2)` signatures in autocomplete for dynamically generated function types, forcing them to rely on external documentation or inline comments to understand the purpose of the arguments. From e4edfeddb82b5bda2a641a904b762b9b22b35b23 Mon Sep 17 00:00:00 2001 From: DavidLoveLuau Date: Tue, 10 Mar 2026 18:11:38 +0300 Subject: [PATCH 3/8] Create type-functions-parameter-names.md --- docs/type-functions-parameter-names.md | 100 +++++++++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 docs/type-functions-parameter-names.md diff --git a/docs/type-functions-parameter-names.md b/docs/type-functions-parameter-names.md new file mode 100644 index 00000000..f86a6c78 --- /dev/null +++ b/docs/type-functions-parameter-names.md @@ -0,0 +1,100 @@ +# Feature name: Parameter Names in types.newfunction + +## Summary +Add the ability to specify parameter names when dynamically constructing function types using the experimental `types.newfunction` API. This will improve code readability, developer experience (DX), and autocomplete integration in tooling such as Luau LSP and Roblox Studio. + +## Motivation +Currently, when a developer generates a custom function type using `types.newfunction(...)`, they can only define the types of the parameters, but not their names. + +Example of the current limitation: + +```luau +local dynamicFuncType = types.newfunction({ + parameters = { + head = { types.string, types.boolean } + }, + returns = { + head = { types.number } + } +}) +``` + +The resulting type is evaluated as `(string, boolean) -> number`. While functionally correct for type-checking, this significantly degrades the developer experience because users of this type lose context about what the `string` and `boolean` arguments actually represent. + +If we compare this to standard static Luau syntax: + +```luau +type MyFunc = (PlayerName: string, IsAdmin: boolean) -> number +``` + +The parameter names `PlayerName` and `IsAdmin` are preserved and heavily utilized by language servers to provide meaningful autocomplete tooltips and signature help. + +Developers increasingly rely on type functions to generate schemas for networking, ECS frameworks, and binary serialization wrappers. Allowing `types.newfunction` to attach names to parameters would bring dynamic type generation on par with static type definitions. + +## Design +We propose extending the configuration table accepted by `types.newfunction` to accommodate parameter names alongside parameter types. + +Based on the current API where `parameters` is an object containing a `head` array of types, here are the proposed approaches: + +### Option 1: Names property in `newfunction` +Add an optional `parameterNames` field to the configuration table. + +```luau +return types.newfunction({ + parameters = { + head = { types.string, types.boolean } + }, + parameterNames = { "PlayerId", "IsAdmin" }, + returns = { + head = { types.number } + } +}) +``` +The resulting type would be correctly evaluated and displayed by language servers as `(PlayerId: string, IsAdmin: boolean) -> number`. + +If the length of the `parameterNames` array does not match the arity of the `parameters.head` table, the type-checker should emit a type error during the type function evaluation to enforce correctness. + +### Option 2: Dict-like syntax in `head` +Allow the `head` array to optionally act as a dictionary where the keys act as the parameter names: + +```luau +return types.newfunction({ + parameters = { + head = { + Var1 = types.boolean, + Var2 = types.string + } + }, + returns = { + head = { types.number } + } +}) +``` +*Note:* Since Luau dictionary order is not guaranteed, this might require compiler-level stability guarantees for keys or could be problematic for strict positional arguments. + +### Option 3: Named parameters via Singletons +Use string singletons as keys in the `head` table to represent names: + +```luau +return types.newfunction({ + parameters = { + head = { + [types.singleton("Var1")] = types.boolean, + [types.singleton("Var2")] = types.string + } + }, + returns = { + head = { types.number } + } +}) +``` +*Note:* Similar to Option 2, this relies on dictionary key ordering which may not be deterministic. + +## Drawbacks +- Increases the complexity of the `types` library API. +- Parameter names in Luau function types do not affect type strictness or execution logic, meaning this change provides no behavioral benefit to the type-checker itself; it is purely a DX and tooling enhancement. +- Options 2 and 3 introduce dictionary keys into `head`, which traditionally expects an ordered array of types. Luau does not guarantee iteration order for non-array keys, which could lead to non-deterministic parameter orders unless specifically handled by the compiler. + +## Alternatives +### Do Nothing +Developers will continue to see anonymous `(type1, type2)` signatures in autocomplete for dynamically generated function types, forcing them to rely on external documentation or inline comments to understand the purpose of the arguments. From 6fb4b3f9d24e36177c7db5f622464758926746a5 Mon Sep 17 00:00:00 2001 From: David Date: Mon, 13 Apr 2026 00:45:04 +0300 Subject: [PATCH 4/8] Create types-newfunction-named-parameters.md --- docs/types-newfunction-named-parameters.md | 97 ++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 docs/types-newfunction-named-parameters.md diff --git a/docs/types-newfunction-named-parameters.md b/docs/types-newfunction-named-parameters.md new file mode 100644 index 00000000..39db89fd --- /dev/null +++ b/docs/types-newfunction-named-parameters.md @@ -0,0 +1,97 @@ +# Parameter Names in `types.newfunction` +## Summary +Add the ability to specify parameter names when dynamically constructing function types using `types.newfunction` and `setparameters`. This will improve code readability and the overall developer experience when working with dynamically generated function types. +## Motivation +Luau already supports named function type arguments in static type annotations, as established by the [Named function type arguments RFC](https://rfcs.luau.org/syntax-named-function-type-args.html). Parameter names are stored inside function type descriptions and are surfaced in tooltips and signature help: +```luau +type MyFunc = (PlayerName: string, IsAdmin: boolean) -> number +-- tooltip shows: (PlayerName: string, IsAdmin: boolean) -> number +``` +However, when a developer generates a custom function type using `types.newfunction(...)`, they can only define the types of the parameters, but not their names. +Example of the current limitation: +```luau +type function foo(): type + return types.newfunction( + { head = { types.string, types.boolean } }, + { head = { types.number } } + ) +end +``` +The resulting type is evaluated as `(string, boolean) -> number`. While functionally correct for type-checking, this significantly degrades the developer experience because users of this type lose context about what the `string` and `boolean` arguments actually represent. +Developers increasingly rely on type functions to generate schemas for networking, ECS frameworks, and binary serialization wrappers. Allowing `types.newfunction` to attach names to parameters would bring dynamic type generation on par with static type definitions. +Since the [Named function type arguments RFC](https://rfcs.luau.org/syntax-named-function-type-args.html) is already implemented, the internal infrastructure for storing parameter names in function types already exists. This proposal only requires exposing that capability through the `types` library API. +## Design +We propose extending the parameters and returns tables accepted by `types.newfunction` and `setparameters` / `setreturns` to accommodate parameter names alongside parameter types. The current API signatures are: +```luau +-- Constructor +types.newfunction(parameters, returns, generics) +-- where: +-- parameters: { head: {type}?, tail: type? } +-- returns: { head: {type}?, tail: type? } +-- generics: {type}? +-- Instance methods +functiontype:setparameters(head: {type}?, tail: type?) +functiontype:setreturns(head: {type}?, tail: type?) +functiontype:parameters(): { head: {type}?, tail: type? } +functiontype:returns(): { head: {type}?, tail: type? } +``` + +### I suggest this design: + +```luau +types.newfunction(parameters, returns, generics): type +-- where: +-- parameters: { head: {[type]: type}?, tail: type? } +-- Instance methods (updated) +functiontype:setparameters(head: {[type]: type}?, tail: type?) +functiontype:parameters(): { head: {[type]: type}?, tail: type? } +``` +When `head` uses singleton keys (`{[type]: type}`), the singleton values act as parameter names and the mapped values act as parameter types. When `head` is a plain array of types (`{type}`), parameters remain anonymous — this is fully backward compatible with the current behavior of `types.newfunction`. +### Examples: +```luau +type function greet(a: type, b: type): type + assert(a:is("singleton") and b:is("singleton")) + local params = { + head = { + [a] = types.string, + [b] = types.number, + }, + } + local returns = { + head = { types.string }, + } + return types.newfunction(params, returns) +end +local fn: greet<"name", "age"> -- (name: string, age: number) -> string +``` + +```luau +type function foo(): type + local params = { + head = { + [types.singleton("PlayerId")] = types.string, + [types.singleton("IsAdmin")] = types.boolean, + }, + } + local returns = { + head = { types.number }, + } + return types.newfunction(params, returns) +end +local fn: foo<> -- (PlayerId: string, IsAdmin: boolean) -> number +``` +Anonymous parameters (current behavior, unchanged): +```luau +type function bar(): type + return types.newfunction( + { head = { types.string, types.number } }, + { head = { types.boolean } } + ) +end +local fn: bar<> -- (string, number) -> boolean +``` +## Drawbacks +- **Making changes to an existing API.** +## Alternatives +### Do Nothing +Developers will continue to see anonymous `(type1, type2)` signatures in autocomplete for dynamically generated function types, forcing them to rely on external documentation or inline comments to understand the purpose of the arguments. As the adoption of user-defined type functions grows, this gap will become increasingly noticeable. From 8ce454295f24d92f92029540098cc8862b0b6882 Mon Sep 17 00:00:00 2001 From: David Date: Mon, 13 Apr 2026 01:22:20 +0300 Subject: [PATCH 5/8] Update types-newfunction-named-parameters.md --- docs/types-newfunction-named-parameters.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/docs/types-newfunction-named-parameters.md b/docs/types-newfunction-named-parameters.md index 39db89fd..b4eb5e23 100644 --- a/docs/types-newfunction-named-parameters.md +++ b/docs/types-newfunction-named-parameters.md @@ -2,7 +2,11 @@ ## Summary Add the ability to specify parameter names when dynamically constructing function types using `types.newfunction` and `setparameters`. This will improve code readability and the overall developer experience when working with dynamically generated function types. ## Motivation -Luau already supports named function type arguments in static type annotations, as established by the [Named function type arguments RFC](https://rfcs.luau.org/syntax-named-function-type-args.html). Parameter names are stored inside function type descriptions and are surfaced in tooltips and signature help: +Luau already supports named function type arguments in static type annotations, as established by the [Named function type arguments RFC](https://rfcs.luau.org/syntax-named-function-type-args.html). +### Prior Art + +- [Function Parameter Names in User-Defined Type Functions](https://github.com/luau-lang/luau/pull/2001) +Parameter names are stored inside function type descriptions and are surfaced in tooltips and signature help: ```luau type MyFunc = (PlayerName: string, IsAdmin: boolean) -> number -- tooltip shows: (PlayerName: string, IsAdmin: boolean) -> number From 163c66cebbd9800206681e2aa2ee4a93a478f67b Mon Sep 17 00:00:00 2001 From: David Date: Mon, 13 Apr 2026 01:23:00 +0300 Subject: [PATCH 6/8] Update types-newfunction-named-parameters.md --- docs/types-newfunction-named-parameters.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/types-newfunction-named-parameters.md b/docs/types-newfunction-named-parameters.md index b4eb5e23..17c3fb97 100644 --- a/docs/types-newfunction-named-parameters.md +++ b/docs/types-newfunction-named-parameters.md @@ -6,6 +6,7 @@ Luau already supports named function type arguments in static type annotations, ### Prior Art - [Function Parameter Names in User-Defined Type Functions](https://github.com/luau-lang/luau/pull/2001) + Parameter names are stored inside function type descriptions and are surfaced in tooltips and signature help: ```luau type MyFunc = (PlayerName: string, IsAdmin: boolean) -> number From af25d18a7625026c8f4a418d663685ca86a6ac8c Mon Sep 17 00:00:00 2001 From: David Date: Mon, 13 Apr 2026 01:34:47 +0300 Subject: [PATCH 7/8] docs: remove old duplicate file type-functions-parameter-names.md --- docs/type-functions-parameter-names.md | 100 ------------------------- 1 file changed, 100 deletions(-) delete mode 100644 docs/type-functions-parameter-names.md diff --git a/docs/type-functions-parameter-names.md b/docs/type-functions-parameter-names.md deleted file mode 100644 index f86a6c78..00000000 --- a/docs/type-functions-parameter-names.md +++ /dev/null @@ -1,100 +0,0 @@ -# Feature name: Parameter Names in types.newfunction - -## Summary -Add the ability to specify parameter names when dynamically constructing function types using the experimental `types.newfunction` API. This will improve code readability, developer experience (DX), and autocomplete integration in tooling such as Luau LSP and Roblox Studio. - -## Motivation -Currently, when a developer generates a custom function type using `types.newfunction(...)`, they can only define the types of the parameters, but not their names. - -Example of the current limitation: - -```luau -local dynamicFuncType = types.newfunction({ - parameters = { - head = { types.string, types.boolean } - }, - returns = { - head = { types.number } - } -}) -``` - -The resulting type is evaluated as `(string, boolean) -> number`. While functionally correct for type-checking, this significantly degrades the developer experience because users of this type lose context about what the `string` and `boolean` arguments actually represent. - -If we compare this to standard static Luau syntax: - -```luau -type MyFunc = (PlayerName: string, IsAdmin: boolean) -> number -``` - -The parameter names `PlayerName` and `IsAdmin` are preserved and heavily utilized by language servers to provide meaningful autocomplete tooltips and signature help. - -Developers increasingly rely on type functions to generate schemas for networking, ECS frameworks, and binary serialization wrappers. Allowing `types.newfunction` to attach names to parameters would bring dynamic type generation on par with static type definitions. - -## Design -We propose extending the configuration table accepted by `types.newfunction` to accommodate parameter names alongside parameter types. - -Based on the current API where `parameters` is an object containing a `head` array of types, here are the proposed approaches: - -### Option 1: Names property in `newfunction` -Add an optional `parameterNames` field to the configuration table. - -```luau -return types.newfunction({ - parameters = { - head = { types.string, types.boolean } - }, - parameterNames = { "PlayerId", "IsAdmin" }, - returns = { - head = { types.number } - } -}) -``` -The resulting type would be correctly evaluated and displayed by language servers as `(PlayerId: string, IsAdmin: boolean) -> number`. - -If the length of the `parameterNames` array does not match the arity of the `parameters.head` table, the type-checker should emit a type error during the type function evaluation to enforce correctness. - -### Option 2: Dict-like syntax in `head` -Allow the `head` array to optionally act as a dictionary where the keys act as the parameter names: - -```luau -return types.newfunction({ - parameters = { - head = { - Var1 = types.boolean, - Var2 = types.string - } - }, - returns = { - head = { types.number } - } -}) -``` -*Note:* Since Luau dictionary order is not guaranteed, this might require compiler-level stability guarantees for keys or could be problematic for strict positional arguments. - -### Option 3: Named parameters via Singletons -Use string singletons as keys in the `head` table to represent names: - -```luau -return types.newfunction({ - parameters = { - head = { - [types.singleton("Var1")] = types.boolean, - [types.singleton("Var2")] = types.string - } - }, - returns = { - head = { types.number } - } -}) -``` -*Note:* Similar to Option 2, this relies on dictionary key ordering which may not be deterministic. - -## Drawbacks -- Increases the complexity of the `types` library API. -- Parameter names in Luau function types do not affect type strictness or execution logic, meaning this change provides no behavioral benefit to the type-checker itself; it is purely a DX and tooling enhancement. -- Options 2 and 3 introduce dictionary keys into `head`, which traditionally expects an ordered array of types. Luau does not guarantee iteration order for non-array keys, which could lead to non-deterministic parameter orders unless specifically handled by the compiler. - -## Alternatives -### Do Nothing -Developers will continue to see anonymous `(type1, type2)` signatures in autocomplete for dynamically generated function types, forcing them to rely on external documentation or inline comments to understand the purpose of the arguments. From 8ffd1128771795be449c843e29fd0c374cf39875 Mon Sep 17 00:00:00 2001 From: David Date: Mon, 13 Apr 2026 01:43:51 +0300 Subject: [PATCH 8/8] Update types-newfunction-named-parameters.md --- docs/types-newfunction-named-parameters.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/types-newfunction-named-parameters.md b/docs/types-newfunction-named-parameters.md index 17c3fb97..19932826 100644 --- a/docs/types-newfunction-named-parameters.md +++ b/docs/types-newfunction-named-parameters.md @@ -3,6 +3,7 @@ Add the ability to specify parameter names when dynamically constructing function types using `types.newfunction` and `setparameters`. This will improve code readability and the overall developer experience when working with dynamically generated function types. ## Motivation Luau already supports named function type arguments in static type annotations, as established by the [Named function type arguments RFC](https://rfcs.luau.org/syntax-named-function-type-args.html). +Being able to add names to parameters defined in user-defined type functions increases the expressiveness of the type system, which is the primary motivation of the original [user-defined type functions RFC](https://github.com/luau-lang/rfcs/pull/45). ### Prior Art - [Function Parameter Names in User-Defined Type Functions](https://github.com/luau-lang/luau/pull/2001)