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] 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