luau-lang/rfcs
1
0
Fork 0
mirror of https://github.com/luau-lang/rfcs.git synced 2025-04-03 18:10:56 +01:00
Code Issues Projects Releases Packages Wiki Activity

Amend per-function-bindings to per-usage-bindings

Browse source 
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`.
This commit is contained in:
Ardi 2025-03-07 10:14:58 -06:00 • committed by GitHub
parent 458dcb645f
commit 8bb92ba760
Signed by: DevComp
GPG key ID: B5690EEEBB952194
1 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
docs/eager-inference-annotations-for-polymorphic-types.md
View file

@ -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<T>(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<T>`. 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