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

changes to alternatives

Browse source
This commit is contained in:
Ardi 2025-03-07 08:09:12 -06:00 • committed by GitHub
parent c9328c7f88
commit 27d8c66b86
Signed by: DevComp
GPG key ID: B5690EEEBB952194
1 changed files with 9 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -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<T>(first: T!, second: T!, third: T): T
function test<T>(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<T>` 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 `<greedy T>` or `<strict T>` should also be considered if we want to reduce symbols.
Something like `<greedy T>` or `<strict T>` 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!?`