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

Update generic-constraints.md

Browse source 
oops; clarified code + added extra periods to make sure that code does not get confused with var args
This commit is contained in:
Kiiyoko 2024-12-12 23:29:12 -05:00 • committed by GitHub
parent e29d515a27
commit dcddfa3dbe
Signed by: DevComp
GPG key ID: B5690EEEBB952194
1 changed files with 9 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
docs/generic-constraints.md
View file

@ -2,8 +2,8 @@
## Summary ## Summary
Introduce syntax to extend/constrain the type of a generic. Introduce syntax to extend/constrain the type of a generic.
## Motivation ## Motivation
Luau currently does not provide a way in order to constrain the type of a generic without direct assertions. Luau currently does not provide a way in order to constrain the type of a generic without direct assertions, and even so, would not properly infer the right type.
```lua ```luau
local qux = { foo = 10, bar = "string" } local qux = { foo = 10, bar = "string" }
local function getProperty<T>( object: T, key: keyof<T> ) local function getProperty<T>( object: T, key: keyof<T> )
@ -17,13 +17,13 @@ local bar = getProperty( qux, "bar" )
``` ```
This is wrong! We would expect foo to be a number, with bar being a string. This is wrong! We would expect foo to be a number, with bar being a string.
In the following snippet, it is impossible to tell whether or not the key variable is the same as the one being used to index T in the callback. In the following snippet, it is impossible to tell whether or not the key variable is the same as the one being used to index T in the callback.
```lua ```luau
local function callbackProperty<T>( object: T, key: keyof<T>, callback: (index<T, keyof<T>>) -> () ) local function callbackProperty<T>( object: T, key: keyof<T>, callback: (index<T, keyof<T>>) -> () )
... ....
``` ```
## Design ## Design
The design of this would take inspiration from TypeScript's `extends`, where instead of the additional keyword, we would use `&`. The design of this would take inspiration from TypeScript's `extends`, where instead of the additional keyword, we would use `&`.
```lua ```luau
local qux = { foo = 10, bar = "string" } local qux = { foo = 10, bar = "string" }
local function getProperty<T, K & keyof<T>>( object: T, key: K ) local function getProperty<T, K & keyof<T>>( object: T, key: K )
@ -37,7 +37,7 @@ local bar = getProperty( qux, "bar" )
``` ```
This would correctly infer the type of the each key's value. This would correctly infer the type of the each key's value.
The following snippet would also thus be correctly inferred. The following snippet would also thus be correctly inferred.
```lua ```luau
local qux = { foo = 10, bar = "string" } local qux = { foo = 10, bar = "string" }
local function callbackProperty<T, K & keyof<T>>( object: T, key: K, callback: (index<T, K>) -> () ) local function callbackProperty<T, K & keyof<T>>( object: T, key: K, callback: (index<T, K>) -> () )
@ -49,9 +49,9 @@ callbackProperty( qux, "foo", function( foo )
end) end)
``` ```
An alternative syntax could be the following, but does not satisfy current requirements about `:` only being used inside `()` and `{}`, and personally does not look as good. An alternative syntax could be the following, but does not satisfy current requirements about `:` only being used inside `()` and `{}`, and personally does not look as good.
```lua ```luau
local function getProperty<T, K: keyof<T>>( object: T, key: K ) ... end local function getProperty<T, K: keyof<T>>( object: T, key: K ) .... end
local function callbackProperty<T, K: keyof<T>>( object: T, key: K, callback: (index<T, K>) -> () ) ... end local function callbackProperty<T, K: keyof<T>>( object: T, key: K, callback: (index<T, K>) -> () ) .... end
``` ```
## Drawbacks ## Drawbacks
- I am not personally familiar with the internals of the typechecker, but this has a chance to further complicate type inference. - I am not personally familiar with the internals of the typechecker, but this has a chance to further complicate type inference.