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

Feedback

Browse source
This commit is contained in:
boyned//Kampfkarren 2025-01-28 09:52:36 -08:00 • committed by GitHub
parent 1f4916cfc9
commit 15f076820a
Signed by: DevComp
GPG key ID: B5690EEEBB952194
1 changed files with 10 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
docs/parameterized-function-expressions.md → docs/explicit-type-parameter-instantiation.md
View file

@ -1,4 +1,4 @@
# Parameterized function expressions # Explicit type parameter instantiation
## Summary ## Summary
@ -80,19 +80,19 @@ Signals.playerTookDamageSignal = createSignal()
We propose allowing the following: We propose allowing the following:
```lua ```lua
-- Saving `f<<T>>` as a variable to called later
local a = f<<T>>
-- Parameterized function call as statement -- Parameterized function call as statement
f<<T, U>>() f<<T, U>>()
-- Parameterized function call as expression -- Parameterized function call as expression
local a = f<<T, U>>() local b = f<<T, U>>()
-- Calling through index -- Calling through index
local b = t.f<<T>>() local c = t.f<<T>>()
local c = t:f<<T>>() local d = t:f<<T>>()
local d = t["f"]<<T>>() local e = t["f"]<<T>>()
-- Saving `f<<T>>` as a variable to called later
local e = f<<T>>
``` ```
For parsing, we will do this by extending `var` to allow `prefixexp '<<' TypeList '>>'`. This will bind the prefixexp equivalent to the substitution of the type parameters. That is to say... For parsing, we will do this by extending `var` to allow `prefixexp '<<' TypeList '>>'`. This will bind the prefixexp equivalent to the substitution of the type parameters. That is to say...
@ -146,9 +146,9 @@ local moneyBinding = React.createBinding.<number>()
local moneyBinding = React.createBinding:<number>() local moneyBinding = React.createBinding:<number>()
``` ```
The downside of these is that they blur the lines between runtime and static, in the sense that `React.createBinding.` starts out as a runtime concept, followed by the purely static `<number>`. As for `:`, it carries the baggage of `x:y()` which will perform a runtime mutation of the function call in the form of adding on `self`. The downside of these is that they blur the lines between runtime and static, in the sense that `React.createBinding.` starts out as a runtime concept, followed by the purely static `<number>`. As for `:`, it carries the baggage of `x:y()` carrying the interesting behavior of adding `self` to the call, which it does not do here.
There is also not necessarily a reason that we have to provide symmetrical operators, so something like `f!T, U()` is reasonably parseable, but is not obviously better. There is also not necessarily a reason that we have to provide symmetrical operators, so something like `f!T, U()` is reasonably parseable, but is not obviously better and is even more unlike any other language's syntax.
Ultimately, this RFC chooses `<<T>>` as a least worst option that is fluid to type, easy to read, and easy to remember. Ultimately, this RFC chooses `<<T>>` as a least worst option that is fluid to type, easy to read, and easy to remember.