From 213ec9f8d43ca211bfb9eab11735fe54ed8c33b1 Mon Sep 17 00:00:00 2001 From: Marcus Date: Wed, 5 Mar 2025 23:32:35 +0100 Subject: [PATCH 01/29] Create monomorphic-type-bindings-for-generics.md --- .../monomorphic-type-bindings-for-generics.md | 56 +++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 docs/monomorphic-type-bindings-for-generics.md diff --git a/docs/monomorphic-type-bindings-for-generics.md b/docs/monomorphic-type-bindings-for-generics.md new file mode 100644 index 0000000..be8299a --- /dev/null +++ b/docs/monomorphic-type-bindings-for-generics.md @@ -0,0 +1,56 @@ +# Monomorphic Type Bindings for Generics + +## Summary + +Introduce a way to opt into monomorphic (greedy) type inference for generics, preventing them from widening into unions when instantiated with different types. + +## Motivation + +Currently, Luau's type solver allows generic parameters to widen into unions when they are instantiated with multiple types. For example: + +```luau +function test(a: T, b: T): T + return a +end + +local result = test(1, "string") -- inferred type: 1 | "string" +``` + +This behaviour can be useful in some cases but is undesirable when a function is intended to enforce strict monomorphism. A monomorphic binding would prevent `T` from being instantiated with different types and instead produce a type error if `b` does not match `a`. + +```luau +function test(a: T, b: T) +end + +test(1, "string") -- Type error: Expected `number`, got `string` +``` + +## Design + +This RFC proposes adding some symbol next to each type variable which is a clear opt-in. + +### New Syntax + +The `T!` syntax would indicate a that the type binding for `T` is monomorphic. + +### Type Checking Rules + +1. When a generic parameter is marked as `T!`: + - The first instantiation of `T` determines its type + - Any subsequent use of `T` in the same context must match this type exactly + - If a different type is encountered, a **type error** is raised + - `T` will not expand into a union + +2. **Behavior in Unions** + - A function or type with `T!` cannot instantiate `T` with a union + - If `T` is already a union, it must remain a union as new types cannot be added to it + +## Drawbacks + +- Introduces a new syntax modifier (`T!`), which may lead to a symbol soup but it doesn't seem too shabby next to `T?`. + +## Alternatives + +- **Type Function Constraint**: Provide a `types.monomorphic` function in user-defined type functions to enforce monomorphism dynamically. But this would probably require some way to propagate an `*error-type*` to the user +- **Keywords**: Something like `` or `` should also be considered if we want to reduce symbols +- **Field-specific bindings**: Flip the relationship from being declared per-type-parameter to be set per-function-parameter such as `function test(a: T, b: T!)` which would imply allow both inference behaviours of generics in an uniform syntax From cb82f7a111582e0c05d8179ccd26609c40b699d7 Mon Sep 17 00:00:00 2001 From: Marcus Date: Wed, 5 Mar 2025 23:33:13 +0100 Subject: [PATCH 02/29] Update monomorphic-type-bindings-for-generics.md --- docs/monomorphic-type-bindings-for-generics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/monomorphic-type-bindings-for-generics.md b/docs/monomorphic-type-bindings-for-generics.md index be8299a..948667b 100644 --- a/docs/monomorphic-type-bindings-for-generics.md +++ b/docs/monomorphic-type-bindings-for-generics.md @@ -53,4 +53,4 @@ The `T!` syntax would indicate a that the type binding for `T` is monomorphic. - **Type Function Constraint**: Provide a `types.monomorphic` function in user-defined type functions to enforce monomorphism dynamically. But this would probably require some way to propagate an `*error-type*` to the user - **Keywords**: Something like `` or `` should also be considered if we want to reduce symbols -- **Field-specific bindings**: Flip the relationship from being declared per-type-parameter to be set per-function-parameter such as `function test(a: T, b: T!)` which would imply allow both inference behaviours of generics in an uniform syntax +- **Function-parameter-bindings**: Flip the relationship from being declared per-type-parameter to be set per-function-parameter such as `function test(a: T, b: T!)` which would imply allow both inference behaviours of generics in an uniform syntax From bf354a1d65d276b94418fa3b1ac926f8a056dfac Mon Sep 17 00:00:00 2001 From: Marcus Date: Wed, 5 Mar 2025 23:51:18 +0100 Subject: [PATCH 03/29] Update and rename monomorphic-type-bindings-for-generics.md to eager-inference-annotations-for-polymorphic-types --- ...ics.md => eager-inference-annotations-for-polymorphic-types} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename docs/{monomorphic-type-bindings-for-generics.md => eager-inference-annotations-for-polymorphic-types} (97%) diff --git a/docs/monomorphic-type-bindings-for-generics.md b/docs/eager-inference-annotations-for-polymorphic-types similarity index 97% rename from docs/monomorphic-type-bindings-for-generics.md rename to docs/eager-inference-annotations-for-polymorphic-types index 948667b..24b76c8 100644 --- a/docs/monomorphic-type-bindings-for-generics.md +++ b/docs/eager-inference-annotations-for-polymorphic-types @@ -1,4 +1,4 @@ -# Monomorphic Type Bindings for Generics +# Eager Inference Annotations for Polymorphic Types ## Summary From 8f1c0d90e06943a358ead425cb070c749d1f3b22 Mon Sep 17 00:00:00 2001 From: Ardi <113623122+hardlyardi@users.noreply.github.com> Date: Wed, 5 Mar 2025 17:12:31 -0600 Subject: [PATCH 04/29] Update "Function-parameter-bindings" alternative --- docs/eager-inference-annotations-for-polymorphic-types | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types b/docs/eager-inference-annotations-for-polymorphic-types index 24b76c8..c9c3d86 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types +++ b/docs/eager-inference-annotations-for-polymorphic-types @@ -53,4 +53,4 @@ The `T!` syntax would indicate a that the type binding for `T` is monomorphic. - **Type Function Constraint**: Provide a `types.monomorphic` function in user-defined type functions to enforce monomorphism dynamically. But this would probably require some way to propagate an `*error-type*` to the user - **Keywords**: Something like `` or `` should also be considered if we want to reduce symbols -- **Function-parameter-bindings**: Flip the relationship from being declared per-type-parameter to be set per-function-parameter such as `function test(a: T, b: T!)` which would imply allow both inference behaviours of generics in an uniform syntax +- **Function-parameter-bindings**: Flip the relationship from being declared per-type-parameter to be set per-function-parameter: `function test(a: T, b: T, c: T!)` which could allow both inference behaviours of polymorphic types under a uniform syntax. From 8a24f5b8fadac9b125c99bb2648c6421a7aeb441 Mon Sep 17 00:00:00 2001 From: Ardi <113623122+hardlyardi@users.noreply.github.com> Date: Wed, 5 Mar 2025 17:15:11 -0600 Subject: [PATCH 05/29] Add .md extension --- ...types => eager-inference-annotations-for-polymorphic-types.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/{eager-inference-annotations-for-polymorphic-types => eager-inference-annotations-for-polymorphic-types.md} (100%) diff --git a/docs/eager-inference-annotations-for-polymorphic-types b/docs/eager-inference-annotations-for-polymorphic-types.md similarity index 100% rename from docs/eager-inference-annotations-for-polymorphic-types rename to docs/eager-inference-annotations-for-polymorphic-types.md From 9df20a06c4f217bb150097d424fbd40df0da8485 Mon Sep 17 00:00:00 2001 From: Marcus Date: Thu, 6 Mar 2025 00:16:44 +0100 Subject: [PATCH 06/29] Update eager-inference-annotations-for-polymorphic-types.md --- docs/eager-inference-annotations-for-polymorphic-types.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index c9c3d86..cc5cda3 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -2,7 +2,7 @@ ## Summary -Introduce a way to opt into monomorphic (greedy) type inference for generics, preventing them from widening into unions when instantiated with different types. +Introduce a way to annotate a polymorphic function signature to express that it will only allow one argument type to interact with automatic instantiation. ## Motivation @@ -27,7 +27,7 @@ test(1, "string") -- Type error: Expected `number`, got `string` ## Design -This RFC proposes adding some symbol next to each type variable which is a clear opt-in. +This RFC proposes adding some symbol as a suffix (or prefix) that annotates the inference behaviour for the generic. ### New Syntax From e25643f37ca3f442f4d1a2f406dc890cbe545b58 Mon Sep 17 00:00:00 2001 From: Ardi <113623122+hardlyardi@users.noreply.github.com> Date: Wed, 5 Mar 2025 18:20:36 -0600 Subject: [PATCH 07/29] change per-function-parameter to per-argument --- docs/eager-inference-annotations-for-polymorphic-types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index cc5cda3..bdf883d 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -53,4 +53,4 @@ The `T!` syntax would indicate a that the type binding for `T` is monomorphic. - **Type Function Constraint**: Provide a `types.monomorphic` function in user-defined type functions to enforce monomorphism dynamically. But this would probably require some way to propagate an `*error-type*` to the user - **Keywords**: Something like `` or `` should also be considered if we want to reduce symbols -- **Function-parameter-bindings**: Flip the relationship from being declared per-type-parameter to be set per-function-parameter: `function test(a: T, b: T, c: T!)` which could allow both inference behaviours of polymorphic types under a uniform syntax. +- **Function-argument-bindings**: Flip the relationship from being declared per-type-parameter to be set per-argument: `function test(a: T, b: T, c: T!)` which could allow both inference behaviours of polymorphic types under a uniform syntax. From 1943be72c3c3fb413a90a9f11c6a269fc67e7d68 Mon Sep 17 00:00:00 2001 From: Ardi <113623122+hardlyardi@users.noreply.github.com> Date: Fri, 7 Mar 2025 01:56:19 -0600 Subject: [PATCH 08/29] change "generic" to "polymorphic type" in a few places --- docs/eager-inference-annotations-for-polymorphic-types.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index bdf883d..b40bc3b 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -6,7 +6,7 @@ Introduce a way to annotate a polymorphic function signature to express that it ## Motivation -Currently, Luau's type solver allows generic parameters to widen into unions when they are instantiated with multiple types. For example: +Currently, Luau's type solver allows polymorphic types to widen into unions when they are instantiated with multiple types. For example: ```luau function test(a: T, b: T): T @@ -27,7 +27,7 @@ test(1, "string") -- Type error: Expected `number`, got `string` ## Design -This RFC proposes adding some symbol as a suffix (or prefix) that annotates the inference behaviour for the generic. +This RFC proposes adding some symbol as a suffix (or prefix) that annotates the inference behaviour for the polymorphic type. ### New Syntax @@ -35,7 +35,7 @@ The `T!` syntax would indicate a that the type binding for `T` is monomorphic. ### Type Checking Rules -1. When a generic parameter is marked as `T!`: +1. When a polymorphic type is marked as `T!`: - The first instantiation of `T` determines its type - Any subsequent use of `T` in the same context must match this type exactly - If a different type is encountered, a **type error** is raised From 1d36401b761bbd221ddc1f2900b78bac98f1f7f7 Mon Sep 17 00:00:00 2001 From: Ardi <113623122+hardlyardi@users.noreply.github.com> Date: Fri, 7 Mar 2025 01:57:33 -0600 Subject: [PATCH 09/29] Punctuation Fixes --- ...nference-annotations-for-polymorphic-types.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index b40bc3b..03dad98 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -36,14 +36,14 @@ The `T!` syntax would indicate a that the type binding for `T` is monomorphic. ### Type Checking Rules 1. When a polymorphic type is marked as `T!`: - - The first instantiation of `T` determines its type - - Any subsequent use of `T` in the same context must match this type exactly - - If a different type is encountered, a **type error** is raised - - `T` will not expand into a union + - The first instantiation of `T` determines its type. + - Any subsequent use of `T` in the same context must match this type exactly. + - If a different type is encountered, a **type error** is raised. + - `T` will not expand into a union. 2. **Behavior in Unions** - - A function or type with `T!` cannot instantiate `T` with a union - - If `T` is already a union, it must remain a union as new types cannot be added to it + - A function or type with `T!` cannot instantiate `T` with a union. + - If `T` is already a union, it must remain a union as new types cannot be added to it. ## Drawbacks @@ -51,6 +51,6 @@ The `T!` syntax would indicate a that the type binding for `T` is monomorphic. ## Alternatives -- **Type Function Constraint**: Provide a `types.monomorphic` function in user-defined type functions to enforce monomorphism dynamically. But this would probably require some way to propagate an `*error-type*` to the user -- **Keywords**: Something like `` or `` should also be considered if we want to reduce symbols +- **Type Function Constraint**: Provide a `types.monomorphic` function in user-defined type functions to enforce monomorphism dynamically. But this would probably require some way to propagate an `*error-type*` to the user. +- **Keywords**: Something like `` or `` should also be considered if we want to reduce symbols. - **Function-argument-bindings**: Flip the relationship from being declared per-type-parameter to be set per-argument: `function test(a: T, b: T, c: T!)` which could allow both inference behaviours of polymorphic types under a uniform syntax. From 1c8d2176cad7be772e7ba4b25747b2c3bc6e8a65 Mon Sep 17 00:00:00 2001 From: Ardi <113623122+hardlyardi@users.noreply.github.com> Date: Fri, 7 Mar 2025 01:59:30 -0600 Subject: [PATCH 10/29] change "inference behavior" to "instantiation behavior" in alternative --- docs/eager-inference-annotations-for-polymorphic-types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index 03dad98..6482e6e 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -53,4 +53,4 @@ The `T!` syntax would indicate a that the type binding for `T` is monomorphic. - **Type Function Constraint**: Provide a `types.monomorphic` function in user-defined type functions to enforce monomorphism dynamically. But this would probably require some way to propagate an `*error-type*` to the user. - **Keywords**: Something like `` or `` should also be considered if we want to reduce symbols. -- **Function-argument-bindings**: Flip the relationship from being declared per-type-parameter to be set per-argument: `function test(a: T, b: T, c: T!)` which could allow both inference behaviours of polymorphic types under a uniform syntax. +- **Function-argument-bindings**: Flip the relationship from being declared per-type-parameter to be set per-argument: `function test(a: T, b: T, c: T!)` which could allow both instantiation behaviours of polymorphic types under a uniform syntax. From 2ed018710c7c807a998dba9bb909f408583f26d8 Mon Sep 17 00:00:00 2001 From: Ardi <113623122+hardlyardi@users.noreply.github.com> Date: Fri, 7 Mar 2025 02:00:12 -0600 Subject: [PATCH 11/29] Update eager-inference-annotations-for-polymorphic-types.md --- docs/eager-inference-annotations-for-polymorphic-types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index 6482e6e..63ab042 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -53,4 +53,4 @@ The `T!` syntax would indicate a that the type binding for `T` is monomorphic. - **Type Function Constraint**: Provide a `types.monomorphic` function in user-defined type functions to enforce monomorphism dynamically. But this would probably require some way to propagate an `*error-type*` to the user. - **Keywords**: Something like `` or `` should also be considered if we want to reduce symbols. -- **Function-argument-bindings**: Flip the relationship from being declared per-type-parameter to be set per-argument: `function test(a: T, b: T, c: T!)` which could allow both instantiation behaviours of polymorphic types under a uniform syntax. +- **Function-argument-bindings**: Flip the relationship from being declared per-type-parameter to be set per-argument: `function test(a: T, b: T, c: T!)` which provides the user more control, and could allow both instantiation behaviours of polymorphic types under a uniform syntax. From b7c28004ca3b178fe1ae505c021c0483ebaac224 Mon Sep 17 00:00:00 2001 From: Ardi <113623122+hardlyardi@users.noreply.github.com> Date: Fri, 7 Mar 2025 02:01:58 -0600 Subject: [PATCH 12/29] add line break --- docs/eager-inference-annotations-for-polymorphic-types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index 63ab042..dfac69a 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -53,4 +53,4 @@ The `T!` syntax would indicate a that the type binding for `T` is monomorphic. - **Type Function Constraint**: Provide a `types.monomorphic` function in user-defined type functions to enforce monomorphism dynamically. But this would probably require some way to propagate an `*error-type*` to the user. - **Keywords**: Something like `` or `` should also be considered if we want to reduce symbols. -- **Function-argument-bindings**: Flip the relationship from being declared per-type-parameter to be set per-argument: `function test(a: T, b: T, c: T!)` which provides the user more control, and could allow both instantiation behaviours of polymorphic types under a uniform syntax. +- **Function-argument-bindings**: Flip the relationship from being declared per-type-parameter to be set per-argument:
`function test(a: T, b: T, c: T!)` which provides the user more control, and could allow both instantiation behaviours of polymorphic types under a uniform syntax. From b47e0009804b83913665e667d5985aa8eab835e5 Mon Sep 17 00:00:00 2001 From: Ardi <113623122+hardlyardi@users.noreply.github.com> Date: Fri, 7 Mar 2025 02:09:09 -0600 Subject: [PATCH 13/29] Update wording in summary automatic instantiation -> implicit instantiation "one type" transitioned to "first usage" for clarity --- docs/eager-inference-annotations-for-polymorphic-types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index dfac69a..c2fcff9 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -2,7 +2,7 @@ ## Summary -Introduce a way to annotate a polymorphic function signature to express that it will only allow one argument type to interact with automatic instantiation. +Introduce a way to annotate a polymorphic function signature to express that it will only allow the first usage of a polymorphic type to interact with implicit instantiation. ## Motivation From 29384afb9fd0dd3f5c23faef16818bf9b00dc593 Mon Sep 17 00:00:00 2001 From: Ardi <113623122+hardlyardi@users.noreply.github.com> Date: Fri, 7 Mar 2025 04:40:30 -0600 Subject: [PATCH 14/29] add comma --- docs/eager-inference-annotations-for-polymorphic-types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index c2fcff9..5badaf6 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -47,7 +47,7 @@ The `T!` syntax would indicate a that the type binding for `T` is monomorphic. ## Drawbacks -- Introduces a new syntax modifier (`T!`), which may lead to a symbol soup but it doesn't seem too shabby next to `T?`. +- Introduces a new syntax modifier (`T!`), which may lead to a symbol soup, but it doesn't seem too shabby next to `T?`. ## Alternatives From f5c5609d77d3aafd84b089c6fd06ae217da33abb Mon Sep 17 00:00:00 2001 From: Marcus Date: Fri, 7 Mar 2025 14:45:12 +0100 Subject: [PATCH 15/29] Update eager-inference-annotations-for-polymorphic-types.md --- ...rence-annotations-for-polymorphic-types.md | 43 ++++++++++++------- 1 file changed, 28 insertions(+), 15 deletions(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index 5badaf6..f0468ae 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -2,21 +2,29 @@ ## Summary -Introduce a way to annotate a polymorphic function signature to express that it will only allow the first usage of a polymorphic type to interact with implicit instantiation. +The RFC introduces a feature to annotate a polymorphic function signature to express that the first instantiation of a polymorphic type T is the one that sticks. ## Motivation -Currently, Luau's type solver allows polymorphic types to widen into unions when they are instantiated with multiple types. For example: +The purpose of this feature is to prevent polymorphic types from widening into a union (e.g., number | string) when the function is called with different arguments, like in the case of `test(1, "a")`. Without the `!` annotation, the solver would infer `T` to be `number | string`, which is undesirable when the intention is to enforce strict type consistency across the function. ```luau function test(a: T, b: T): T return a end -local result = test(1, "string") -- inferred type: 1 | "string" +local result = test(1, "string") -- inferred type: number | string" ``` -This behaviour can be useful in some cases but is undesirable when a function is intended to enforce strict monomorphism. A monomorphic binding would prevent `T` from being instantiated with different types and instead produce a type error if `b` does not match `a`. +This behaviour can be useful in some cases but is undesirable when a function is intended to constrain the type to. An eager binding would prevent `T` from being instantiated with different types and instead produce a type error if `b` does not match `a`. + +## Design + +We propose adding some symbol as a suffix (or prefix) that annotates the inference behaviour for the polymorphic type. + +### New Syntax + +The `T!` syntax would would enforce an eager inference behaviour for `T`. ```luau function test(a: T, b: T) @@ -25,13 +33,6 @@ end test(1, "string") -- Type error: Expected `number`, got `string` ``` -## Design - -This RFC proposes adding some symbol as a suffix (or prefix) that annotates the inference behaviour for the polymorphic type. - -### New Syntax - -The `T!` syntax would indicate a that the type binding for `T` is monomorphic. ### Type Checking Rules @@ -41,7 +42,7 @@ The `T!` syntax would indicate a that the type binding for `T` is monomorphic. - If a different type is encountered, a **type error** is raised. - `T` will not expand into a union. -2. **Behavior in Unions** +2. **Behaviour in Unions** - A function or type with `T!` cannot instantiate `T` with a union. - If `T` is already a union, it must remain a union as new types cannot be added to it. @@ -50,7 +51,19 @@ The `T!` syntax would indicate a that the type binding for `T` is monomorphic. - Introduces a new syntax modifier (`T!`), which may lead to a symbol soup, but it doesn't seem too shabby next to `T?`. ## Alternatives +### Function-argument-bindings +Flip the relationship being declarared per-type-parameter to be per-argument which provides more control in expressing the inference and could allow both instantiation behaviours of polymorphic types under an uniform syntax. + +A polymorphic function has arguments marked with T! will not contribute to the inference of `T`. Instead `T` should be inferred on the arguments without the annotation. +```luau +function test(first: T!, second: T!, third: T): T +end + +test(1, "string", true) -- Type error: Expected `boolean`, got `number` +``` +### Type Function Constraint +Provide a `types.monomorphic` function in user-defined type functions to enforce monomorphism dynamically. But this would probably require some way to propagate an `*error-type*` to the user. +### Keywords +Something like `` or `` should also be considered if we want to reduce symbols. + -- **Type Function Constraint**: Provide a `types.monomorphic` function in user-defined type functions to enforce monomorphism dynamically. But this would probably require some way to propagate an `*error-type*` to the user. -- **Keywords**: Something like `` or `` should also be considered if we want to reduce symbols. -- **Function-argument-bindings**: Flip the relationship from being declared per-type-parameter to be set per-argument:
`function test(a: T, b: T, c: T!)` which provides the user more control, and could allow both instantiation behaviours of polymorphic types under a uniform syntax. From b995140a1e35c71a131f3bfe1f131a26e3e4e975 Mon Sep 17 00:00:00 2001 From: Ardi <113623122+hardlyardi@users.noreply.github.com> Date: Fri, 7 Mar 2025 07:50:30 -0600 Subject: [PATCH 16/29] remove redundant "union behavior" --- docs/eager-inference-annotations-for-polymorphic-types.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index f0468ae..7cb7680 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -42,10 +42,6 @@ test(1, "string") -- Type error: Expected `number`, got `string` - If a different type is encountered, a **type error** is raised. - `T` will not expand into a union. -2. **Behaviour in Unions** - - A function or type with `T!` cannot instantiate `T` with a union. - - If `T` is already a union, it must remain a union as new types cannot be added to it. - ## Drawbacks - Introduces a new syntax modifier (`T!`), which may lead to a symbol soup, but it doesn't seem too shabby next to `T?`. From 5308d81184b8acceef08f24ff8cb7558863d468d Mon Sep 17 00:00:00 2001 From: Marcus Date: Fri, 7 Mar 2025 14:51:48 +0100 Subject: [PATCH 17/29] Update eager-inference-annotations-for-polymorphic-types.md --- docs/eager-inference-annotations-for-polymorphic-types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index 7cb7680..fc74aa7 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -6,7 +6,7 @@ The RFC introduces a feature to annotate a polymorphic function signature to exp ## Motivation -The purpose of this feature is to prevent polymorphic types from widening into a union (e.g., number | string) when the function is called with different arguments, like in the case of `test(1, "a")`. Without the `!` annotation, the solver would infer `T` to be `number | string`, which is undesirable when the intention is to enforce strict type consistency across the function. +The purpose of this feature is to prevent polymorphic types from widening into (e.g., number | string) when the function is called with different arguments, like in the case of `test(1, "a")`. Without the `!` annotation, the solver would infer `T` to be `number | string`, which is undesirable when the intention is to enforce strict type consistency across the function. ```luau function test(a: T, b: T): T From c9328c7f88e634127ca600595907815f7bc643ab Mon Sep 17 00:00:00 2001 From: Marcus Date: Fri, 7 Mar 2025 14:55:08 +0100 Subject: [PATCH 18/29] Update eager-inference-annotations-for-polymorphic-types.md --- .../eager-inference-annotations-for-polymorphic-types.md | 9 --------- 1 file changed, 9 deletions(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index fc74aa7..1a0e4e9 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -33,15 +33,6 @@ end test(1, "string") -- Type error: Expected `number`, got `string` ``` - -### Type Checking Rules - -1. When a polymorphic type is marked as `T!`: - - The first instantiation of `T` determines its type. - - Any subsequent use of `T` in the same context must match this type exactly. - - If a different type is encountered, a **type error** is raised. - - `T` will not expand into a union. - ## Drawbacks - Introduces a new syntax modifier (`T!`), which may lead to a symbol soup, but it doesn't seem too shabby next to `T?`. From 27d8c66b864c7e00ecd7e62fff2477a7a71d4566 Mon Sep 17 00:00:00 2001 From: Ardi <113623122+hardlyardi@users.noreply.github.com> Date: Fri, 7 Mar 2025 08:09:12 -0600 Subject: [PATCH 19/29] changes to alternatives --- ...-inference-annotations-for-polymorphic-types.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index 1a0e4e9..9815f03 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -39,18 +39,22 @@ test(1, "string") -- Type error: Expected `number`, got `string` ## Alternatives ### Function-argument-bindings -Flip the relationship being declarared per-type-parameter to be per-argument which provides more control in expressing the inference and could allow both instantiation behaviours of polymorphic types under an uniform syntax. +Flip the relationship being declarared per-type-parameter to be per-argument which provides more control in expressing the inference, and could allow both instantiation behaviours of polymorphic types under a uniform syntax. -A polymorphic function has arguments marked with T! will not contribute to the inference of `T`. Instead `T` should be inferred on the arguments without the annotation. +A polymorphic function's arguments marked with type `T!` will not contribute to the instantiation of type `T` in the function. Instead, `T` should be inferred on the arguments without the annotation. ```luau -function test(first: T!, second: T!, third: T): T +function test(first: T, second: T, third: T!): T end -test(1, "string", true) -- Type error: Expected `boolean`, got `number` +test(1, "string", true) -- TypeError: Type `boolean` could not be converted into `number | string` ``` + + ### Type Function Constraint Provide a `types.monomorphic` function in user-defined type functions to enforce monomorphism dynamically. But this would probably require some way to propagate an `*error-type*` to the user. + + ### Keywords -Something like `` or `` should also be considered if we want to reduce symbols. +Something like `` or `` should also be considered if we want to reduce symbols. This idea has merit when considering the potential complexity of type aliases combined with `T!?` From cbc02bd235079c3887e426338c46bc5101466b8f Mon Sep 17 00:00:00 2001 From: Ardi <113623122+hardlyardi@users.noreply.github.com> Date: Fri, 7 Mar 2025 08:54:15 -0600 Subject: [PATCH 20/29] general changes + rephrasing --- ...rence-annotations-for-polymorphic-types.md | 33 ++++++++++--------- 1 file changed, 18 insertions(+), 15 deletions(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index 9815f03..73aace0 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -2,46 +2,50 @@ ## Summary -The RFC introduces a feature to annotate a polymorphic function signature to express that the first instantiation of a polymorphic type T is the one that sticks. +The RFC introduces a feature to annotate polymorphic function types to express that the first instantiation of a polymorphic type T is the one that sticks. ## Motivation -The purpose of this feature is to prevent polymorphic types from widening into (e.g., number | string) when the function is called with different arguments, like in the case of `test(1, "a")`. Without the `!` annotation, the solver would infer `T` to be `number | string`, which is undesirable when the intention is to enforce strict type consistency across the function. +The purpose of this feature is to dvelop syntax to prevent polymorphic types from widening into (e.g., number | string) when a function is implicitly instantiated with different argument types. E.g., `test(1, "a")`. In the following code, Luau's current solver infers `T` to be of a union type: ```luau function test(a: T, b: T): T return a end -local result = test(1, "string") -- inferred type: number | string" +local result = test(1, "string") -- inferred type `T`: number | string" ``` -This behaviour can be useful in some cases but is undesirable when a function is intended to constrain the type to. An eager binding would prevent `T` from being instantiated with different types and instead produce a type error if `b` does not match `a`. +This behaviour can be useful in some cases but is undesirable when a polymorphic function is intended to constrain the input types to be consistent. ## Design -We propose adding some symbol as a suffix (or prefix) that annotates the inference behaviour for the polymorphic type. +We propose adding some symbol as a suffix (or prefix) that annotates the "eager" inference behaviour for a polymorphic type. +Subsequent usages of type `T` where `T` is "eager" would be ignored during instantiation. -### New Syntax +### New Syntax -The `T!` syntax would would enforce an eager inference behaviour for `T`. +The `!` syntax modifier would would enforce an eager inference behaviour for `T!`: ```luau -function test(a: T, b: T) +function test(a: T, b: T): T + return a end -test(1, "string") -- Type error: Expected `number`, got `string` +test(1, "string") -- TypeError: Expected `number`, got `string` ``` ## Drawbacks - Introduces a new syntax modifier (`T!`), which may lead to a symbol soup, but it doesn't seem too shabby next to `T?`. +- Introduces a simple change to luau's parser, marginally increasing parsing complexity. ## Alternatives ### Function-argument-bindings -Flip the relationship being declarared per-type-parameter to be per-argument which provides more control in expressing the inference, and could allow both instantiation behaviours of polymorphic types under a uniform syntax. +Flip the relationship being declarared per-type-parameter to per-function-argument which provides more control in expressing the inference, and could allow both instantiation behaviours of polymorphic types under a uniform syntax. + +A polymorphic function's arguments marked with type `T!` will not contribute to the instantiation of type `T` in the function. Instead, `T` should be inferred on the arguments without the annotation: -A polymorphic function's arguments marked with type `T!` will not contribute to the instantiation of type `T` in the function. Instead, `T` should be inferred on the arguments without the annotation. ```luau function test(first: T, second: T, third: T!): T end @@ -49,12 +53,11 @@ end test(1, "string", true) -- TypeError: Type `boolean` could not be converted into `number | string` ``` - -### Type Function Constraint -Provide a `types.monomorphic` function in user-defined type functions to enforce monomorphism dynamically. But this would probably require some way to propagate an `*error-type*` to the user. +This has the added drawback that the `!` syntax modifier would need to be barred from return types, as the return type holds no relevance to implicit instantiation. ### Keywords Something like `` or `` should also be considered if we want to reduce symbols. This idea has merit when considering the potential complexity of type aliases combined with `T!?` - +### Type Function Constraint +Provide a `types.monomorphic` function accessible in luau's type runtime to enforce monomorphism dynamically. This could be implemented separately at a later date. From 9fa24be227e9364c3a65bc8c8ff6817c9fdee4c4 Mon Sep 17 00:00:00 2001 From: Ardi <113623122+hardlyardi@users.noreply.github.com> Date: Fri, 7 Mar 2025 08:55:08 -0600 Subject: [PATCH 21/29] add single char monospace --- docs/eager-inference-annotations-for-polymorphic-types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index 73aace0..467deea 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -2,7 +2,7 @@ ## Summary -The RFC introduces a feature to annotate polymorphic function types to express that the first instantiation of a polymorphic type T is the one that sticks. +The RFC introduces a feature to annotate polymorphic function types to express that the first instantiation of a polymorphic type `T` is the one that sticks. ## Motivation From 96f8aaa3a2b79d2d2e0d33e2339ce12752a54bfa Mon Sep 17 00:00:00 2001 From: Marcus Date: Fri, 7 Mar 2025 15:57:47 +0100 Subject: [PATCH 22/29] Update eager-inference-annotations-for-polymorphic-types.md --- docs/eager-inference-annotations-for-polymorphic-types.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index 467deea..18d277d 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -58,6 +58,3 @@ This has the added drawback that the `!` syntax modifier would need to be barred ### Keywords Something like `` or `` should also be considered if we want to reduce symbols. This idea has merit when considering the potential complexity of type aliases combined with `T!?` - -### Type Function Constraint -Provide a `types.monomorphic` function accessible in luau's type runtime to enforce monomorphism dynamically. This could be implemented separately at a later date. From b83c473db5bde01c330ebe7c4a7aa1804f014752 Mon Sep 17 00:00:00 2001 From: Ardi <113623122+hardlyardi@users.noreply.github.com> Date: Fri, 7 Mar 2025 09:01:20 -0600 Subject: [PATCH 23/29] small consistency/grammar change --- docs/eager-inference-annotations-for-polymorphic-types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index 18d277d..74455ed 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -37,7 +37,7 @@ test(1, "string") -- TypeError: Expected `number`, got `string` ## Drawbacks -- Introduces a new syntax modifier (`T!`), which may lead to a symbol soup, but it doesn't seem too shabby next to `T?`. +- Introduces a new syntax modifier `!`, which may lead to a symbol soup. However, `T!` doesn't seem too shabby next to `T?`. - Introduces a simple change to luau's parser, marginally increasing parsing complexity. ## Alternatives From 1fee95b001a01ac88d5feaadf9a3865ac58857f9 Mon Sep 17 00:00:00 2001 From: Ardi <113623122+hardlyardi@users.noreply.github.com> Date: Fri, 7 Mar 2025 09:03:11 -0600 Subject: [PATCH 24/29] add return statement --- docs/eager-inference-annotations-for-polymorphic-types.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index 74455ed..a20fc60 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -48,6 +48,7 @@ A polymorphic function's arguments marked with type `T!` will not contribute to ```luau function test(first: T, second: T, third: T!): T + return first end test(1, "string", true) -- TypeError: Type `boolean` could not be converted into `number | string` From 458dcb645fdf9fb097613105d5f075fb59e31716 Mon Sep 17 00:00:00 2001 From: Ardi <113623122+hardlyardi@users.noreply.github.com> Date: Fri, 7 Mar 2025 09:37:25 -0600 Subject: [PATCH 25/29] fix spelling :( --- docs/eager-inference-annotations-for-polymorphic-types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index a20fc60..32e0894 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -6,7 +6,7 @@ The RFC introduces a feature to annotate polymorphic function types to express t ## Motivation -The purpose of this feature is to dvelop syntax to prevent polymorphic types from widening into (e.g., number | string) when a function is implicitly instantiated with different argument types. E.g., `test(1, "a")`. In the following code, Luau's current solver infers `T` to be of a union type: +The purpose of this feature is to develop syntax to prevent polymorphic types from widening into (e.g., number | string) when a function is implicitly instantiated with different argument types. E.g., `test(1, "a")`. In the following code, Luau's current solver infers `T` to be of a union type: ```luau function test(a: T, b: T): T From 8bb92ba76029cb2aeedc56132fcec07ce9b6e48d Mon Sep 17 00:00:00 2001 From: Ardi <113623122+hardlyardi@users.noreply.github.com> Date: Fri, 7 Mar 2025 10:14:58 -0600 Subject: [PATCH 26/29] Amend per-function-bindings to per-usage-bindings It was pointed out in an external channel that this alternative was unnecessarily restrictive. The original intent was to allow flexibility for each usage of `T`. --- docs/eager-inference-annotations-for-polymorphic-types.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index 32e0894..7079b78 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -41,10 +41,10 @@ test(1, "string") -- TypeError: Expected `number`, got `string` - Introduces a simple change to luau's parser, marginally increasing parsing complexity. ## Alternatives -### Function-argument-bindings -Flip the relationship being declarared per-type-parameter to per-function-argument which provides more control in expressing the inference, and could allow both instantiation behaviours of polymorphic types under a uniform syntax. +### Per-usage-bindings +Flip the relationship being declarared per-type-parameter to per-usage which provides more control in expressing the inference, and could allow both instantiation behaviours of polymorphic types under a uniform syntax. -A polymorphic function's arguments marked with type `T!` will not contribute to the instantiation of type `T` in the function. Instead, `T` should be inferred on the arguments without the annotation: +A polymorphic typed marked with type `T!` will not contribute to the instantiation of type `T` in the function. Instead, `T` should be inferred on the arguments without the annotation: ```luau function test(first: T, second: T, third: T!): T @@ -54,7 +54,7 @@ end test(1, "string", true) -- TypeError: Type `boolean` could not be converted into `number | string` ``` -This has the added drawback that the `!` syntax modifier would need to be barred from return types, as the return type holds no relevance to implicit instantiation. +Notably, this behavior would be identical to other languages, such as typescript's `noinfer`. This has the added drawback that the `!` syntax modifier would need to be barred from return types, as the return type holds no relevance to implicit instantiation. ### Keywords From 7d20d52f3ca3b5d2a79084fd85468cb8521579b3 Mon Sep 17 00:00:00 2001 From: Ardi <113623122+hardlyardi@users.noreply.github.com> Date: Fri, 7 Mar 2025 11:16:52 -0600 Subject: [PATCH 27/29] separate noinfer alternative for clarity --- ...er-inference-annotations-for-polymorphic-types.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index 7079b78..dc95b58 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -54,8 +54,18 @@ end test(1, "string", true) -- TypeError: Type `boolean` could not be converted into `number | string` ``` -Notably, this behavior would be identical to other languages, such as typescript's `noinfer`. This has the added drawback that the `!` syntax modifier would need to be barred from return types, as the return type holds no relevance to implicit instantiation. +This has the added drawback that the `!` syntax modifier would need to be barred from return types, as the return type holds no relevance to implicit instantiation. +### noinfer\ +Same as above, except we introduce no new syntax into the language. Create a binding similar or equivalent to typescript's noinfer: + +```luau +function test(first: T, second: T, third: noinfer): T + return first +end + +test(1, "string", true) -- TypeError: Type `boolean` could not be converted into `number | string` +``` ### Keywords Something like `` or `` should also be considered if we want to reduce symbols. This idea has merit when considering the potential complexity of type aliases combined with `T!?` From 246344756301343874c601e339655568019b7694 Mon Sep 17 00:00:00 2001 From: Ardi <113623122+hardlyardi@users.noreply.github.com> Date: Fri, 7 Mar 2025 12:00:58 -0600 Subject: [PATCH 28/29] Update eager-inference-annotations-for-polymorphic-types.md --- ...ger-inference-annotations-for-polymorphic-types.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index dc95b58..481e9db 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -6,7 +6,7 @@ The RFC introduces a feature to annotate polymorphic function types to express t ## Motivation -The purpose of this feature is to develop syntax to prevent polymorphic types from widening into (e.g., number | string) when a function is implicitly instantiated with different argument types. E.g., `test(1, "a")`. In the following code, Luau's current solver infers `T` to be of a union type: +The purpose of this feature is to develop syntax to prevent polymorphic types from widening into (e.g., number | string) when a function is implicitly instantiated with different argument types. E.g., `test(1, "a")`. In the following code, Luau's Type Inference Engine V2 infers `T` to be of a union type: ```luau function test(a: T, b: T): T @@ -16,12 +16,12 @@ end local result = test(1, "string") -- inferred type `T`: number | string" ``` -This behaviour can be useful in some cases but is undesirable when a polymorphic function is intended to constrain the input types to be consistent. +This behaviour can be useful in some cases but is undesirable when a polymorphic type is intended to constrain the subsequent input types to be identical to the first usage. ## Design We propose adding some symbol as a suffix (or prefix) that annotates the "eager" inference behaviour for a polymorphic type. -Subsequent usages of type `T` where `T` is "eager" would be ignored during instantiation. +Subsequent uses of a polymorphic type `T` where `T` is "eager" will be inferred as the precise type of the first occurrence. ### New Syntax @@ -55,9 +55,10 @@ test(1, "string", true) -- TypeError: Type `boolean` could not be converted into ``` This has the added drawback that the `!` syntax modifier would need to be barred from return types, as the return type holds no relevance to implicit instantiation. +Also has the major drawback of symbol complexity. E.g., type aliases with `T!?` are entirely possible under this model. ### noinfer\ -Same as above, except we introduce no new syntax into the language. Create a binding similar or equivalent to typescript's noinfer: +Same as above, except we introduce no new syntax, symbol usage, etc. into the language. Create a binding similar or equivalent to typescript's noinfer: ```luau function test(first: T, second: T, third: noinfer): T @@ -68,4 +69,4 @@ test(1, "string", true) -- TypeError: Type `boolean` could not be converted into ``` ### Keywords -Something like `` or `` should also be considered if we want to reduce symbols. This idea has merit when considering the potential complexity of type aliases combined with `T!?` +Something like `` or `` should also be considered if we want to reduce symbols. From 62642493e5334455cfc506747c964c34c575390d Mon Sep 17 00:00:00 2001 From: Marcus Date: Fri, 7 Mar 2025 19:41:20 +0100 Subject: [PATCH 29/29] Update eager-inference-annotations-for-polymorphic-types.md --- docs/eager-inference-annotations-for-polymorphic-types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/eager-inference-annotations-for-polymorphic-types.md b/docs/eager-inference-annotations-for-polymorphic-types.md index 481e9db..eba8c8e 100644 --- a/docs/eager-inference-annotations-for-polymorphic-types.md +++ b/docs/eager-inference-annotations-for-polymorphic-types.md @@ -2,7 +2,7 @@ ## Summary -The RFC introduces a feature to annotate polymorphic function types to express that the first instantiation of a polymorphic type `T` is the one that sticks. +The RFC introduces a feature to annotate polymorphic function types to express that the first bind to `T` will be the one that sticks. ## Motivation