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

Try to simplify RFC and cut word count; add grammar

Browse source
This commit is contained in:
Dev Chrysalis Dalal 2025-03-27 01:49:14 -05:00
parent 1f23b3f029
commit 14179052b9
1 changed files with 61 additions and 195 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

256
docs/syntax-if-while-local-initializers.md
View file

@ -6,13 +6,13 @@ This RFC is an update and continuation to [if statement initializers](https://gi
`if local statements`: Allow `local` identifiers to be bound in `if` statements to improve the ergonomics of extremely common control flow idioms, improve code clarity, reduce scope pollution, and improve the developer experience.
`while local statements`: Allow `local` identifiers to be bound in `while` statements to allow them to be used in the loop's condition (and body), improve code clarity, and improve control flow.
`while local statements`: Allow `local` identifiers to be bound in `while` statements, re-evaluated upon iteration, and visible in the loop's evaluation condition and `do` body to provide for better control flow.
## Motivation
Declaring locally-scoped variables at the point of use in `if` statements simplifies code, better conveys the programmer's intent, and leads to more readable and better understandable program logic. By combining `if` condition initializers with nilchecks, users can easily handle success/empty conditions and expressively declare control flow.
Declaring locally-scoped variables at the point of use in `if` statements simplifies code, better conveys programmer intent, and leads to more readable and better understandable program logic. By combining `if` condition initializers with nilchecks, users can easily handle success/empty conditions and expressively declare control flow.
In Luau, an extremely common idiom is for fallible functions to return an optional value: an intended result if the operation succeeds or `nil` if it fails. Users are expected to *`nil`check* this result to handle success and failure/empty cases, and this constitutes a major aspect of control flow. An extremely common example of such is Roblox's `Instance:FindFirstChild`, which returns an `Instance` if one was found or nil otherwise:
In Luau, an extremely common idiom is for fallible functions to return an optional value. Users are expected to *`nil`check* this result to handle success and failure/empty cases, and this constitutes a major aspect of control flow. An extremely common example of such is Roblox's `Instance:FindFirstChild`, which returns an `Instance` if one was found or nil otherwise:
```luau
local model = workspace:FindFirstChild("MyModel")
@ -22,7 +22,7 @@ end
-- model is still bound here
```
With `if local` statements, this code may be rewritten as:
`if local` statements can simplify this code to:
```luau
if local model = workspace:FindFirstChild("MyModel") then
@ -31,8 +31,6 @@ end
-- model is not bound here
```
In such cases, `if local` statements better express the programmer's intent and more clearly state the intended control flow.
In many cases, developers use an expression in an if statement's condition and then immediately use it again in its body. Not only does this result in dense, duplicated code, but it also evaluates the expression twice:
```luau
@ -51,7 +49,7 @@ then
end
```
A simple indexing operation may not be expensive, but if the user wants to call a function instead, they often must call it twice to achieve the intended behavior or bind it outside the `if` statement and pollute the outer scope.
A simple indexing operation may not be expensive, but if the user wants to call a function instead, they often must call it twice to achieve the intended behavior or bind it outside the `if` statement.
In this (surprisingly common) example, the user calls `table.find` twice to avoid the `table.remove(t, table.find(t, element))` footgun:
@ -61,9 +59,7 @@ if table.find(array, element) then
end
```
In this case, the user chooses to iterate over the array twice instead of assigning index to a local variable, saving a line of code and a `local` binding.
With an `if local` statement, the user can write the code they desire even more succinctly in a more readable way, without having to iterate over the array twice, nor keep `index` bound unnecessarily in the outer scope:
With an `if local` statement, the user can rewrite the code without iterating over the array twice, nor keeping `index` bound unnecessarily in the outer scope:
```luau
if local index = table.find(array, element) then
@ -73,7 +69,7 @@ end
A significant amount of code (especially on Roblox) needs to do multiple (often nested) checks before executing the condition they want to focus on.
With `if local` stacks (`multi-local`s), such nested checks may be rewritten like:
With `if local` stacks, such nested checks may be rewritten like:
```luau
local function initializeUi()
@ -92,116 +88,11 @@ local function initializeUi()
end
```
The primary motivation for `if local` statements isn't even in small examples like those above, however, it's how it fits into whole codebases. `if local`s can drastically improve code shape, readability, and the general conciseness and expressiveness of the Luau language.
Basically, `if local`s can drastically improve code shape, readability, and the general conciseness and expressiveness of the Luau language.
Take this non-trivial example for instance, where we're trying to read `.csv`s into a data structure. Assume `fs.find` returns a table with fields `file` or `dir` which are optional tables.
`while local` statements instantiate bindings which are visible in the conditional evaluation expression of the loop as well as the loop body. These can be easily compared to `while let` loops in Rust, which serve a similar purpose.
```luau
-- find and read data csv files
type CsvData = {
[string]: {
{ string },
},
}
local function get_input_csvs(): CsvData
local input_dir = input.get("input data dir: ")
local cleaned_input_dir = string.gsub(input_dir, "\n", "")
if #cleaned_input_dir > 0 then
input_dir = cleaned_input_dir
else
print("forgot to enter a path? try again")
return get_input_csvs()
end
local data_dir = fs.find(input_dir).dir
if not data_dir then
print("invalid input dir, please try again")
return get_input_csvs()
end
local data: CsvData = {}
for _, entry in data_dir:entries() do
if entry.type ~= "File" then
continue -- skip dirs
end
local filename = entry.name
if string.find(filename, "%.csv$") then
local lines: { string } = {}
for line_number, line in entry:readlines() do
local line_split = string.split(line)
-- last column is usually empty
if string.gsub(line_split[#line_split], "%s", "") == "" then
table.remove(line_split, #line_split)
end
table.insert(lines, line_split)
end
data[filename] = lines
end
end
return data
end
```
With `if local`s, we can rewrite it to:
```luau
type CsvData = {
[string]: {
{ string }
}
}
local function get_input_files(): CsvData
local input_path = input.get("input data dir: ")
if local stripped_path = string.gsub(input_path, "\n", "") in #stripped_path > 0 then
input_path = stripped_path
else
print("forget to enter a path? try again")
return get_input_csvs()
end
local data: CsvData = {}
if local input_dir = fs.find(input_path).dir then
for _, entry in input_dir:entries() do
if
local file = entry in entry.type == "File"
local filename = file.name in string.find(filename, "%.csv$")
local lines: { string } = {}
then
for line_number, line in file:readlines() do
local line_split = string.split(line) -- default splits by commas
if -- last_column is (almost always) empty
local last_column = line_split[#line_split]
in string.gsub(last_column, "%s", "") == ""
then
table.remove(line_split, #split_lines)
end
table.insert(lines, line_split)
end
data[filename] = lines
end
end
else
print("invalid data dir, please try again")
return get_input_files()
end
return data
end
```
This example shows how `if local` statements can be used to simplify control flow, enhance readability by defining variables in an `if local` stack header (alongside their checks), and clarify the main purpose of the function.
`while local` statements allow you to set a value that can be checked in the conditional expression of the loop and also be used within the loop body.
```luau
while local line = nextline() do -- iteration stops when nextline() returns nil
print(line)
end
```
Here's a more useful example that combines `if local`s with `while local`s to read `require` aliases from `.luaurc`s:
Here's a useful example that combines `if local`s with `while local`s to read `require` aliases from `.luaurc`s:
```luau
local luaurcs_found: { string } = {}
@ -230,7 +121,21 @@ end
## Design
This proposal introduces `if local` and `while local` statements, or more precisely, allows `local` bindings to be initialized within `if` and `while` statement declarations respectively. This RFC refers these two features as `if local` and `while local` statements to distinguish their mental models from those of regular `if` and `while` statements—and because that's how users refer to them anyway.
This proposal introduces `if local` and `while local` statements, or more precisely, allows `local` bindings to be initialized within the expression portions of `if` and `while` statement declarations respectively.
Note that this RFC refers these two features as `if local` and `while local` statements to distinguish their mental models from those of regular `if` and `while` statements—and because it's how users refer to them anyway.
The grammar for `if` and `while` statements shall be changed to the following:
```ebnf
stat ::= varlist '=' explist |
...
'while' ifwhilecond 'do' block 'end' |
...
'if' ifwhilecond 'then' block {'elseif' ifwhilecond 'then' block} ['else' block] 'end' |
...
ifwhilecond ::= exp | {'local' bindinglist '=' explist ['in' exp][';']}
```
### `if local` statements
@ -247,10 +152,7 @@ if local identifier = expression() then
end
-- or
if local identifier = expression() in condition() then
end
-- or
if local identifier = expression() then
elseif local differentidentifier = expression() then
elseif local different_identifier = expr() then
end
-- or
if
@ -268,16 +170,13 @@ end
If `local` bindings are provided, then one optional `in` clause may be provided per `local`-`in` clause to partially determine the evaluation condition of the `if/elseif` branch.
- If an `in` clause is not provided, then the evaluation condition of the branch is that the leftmost binding must evaluate not-`nil`.
- This is roughly similar to the current behavior of calling a multiret function in `if` statement condition (except with a `nil` check instead of a truthiness check) in which the conditional branch will evaluate if the first return of the multiret is truthy.
- This is roughly similar to the current behavior of calling a multiret function in `if` statement condition in which the conditional branch will evaluate if the first return of the multiret is truthy (except with a `nil` check instead of a truthiness check).
- If an `in` clause is provided, then the clause must be satisfied ***and*** the leftmost binding must evaluate not-`nil`.
- The `in` clause will not be evaluated if the leftmost binding is `nil`.
Although this behavior somewhat differs from the previous RFC, this is because the purpose of an `if local` initializer is to check if values exist, and if they do, to bind them. Since fallthrough is not allowed by this RFC, there isn't a major usecase for allowing for the main `local` binding to be `nil`.
This makes the behavior of `if local`s with `in` clauses *more consistent* with `if local`s without `in` clauses.
By expecting the leftmost binding to always exist, we can better support the primary usecase (only one binding) by allowing users to omit the `character ~= nil` or `character and` `nil` checks in the following example:
This makes the behavior of `if local`s with `in` clauses *more consistent* with `if local`s without `in` clauses. This also allows us to prioritize the most common usecase (a single `local` binding), allowing users to omit the `character ~= nil` or `character and` `nil` checks in the following example:
```luau
if local character = player.Character
@ -289,9 +188,9 @@ then
end
```
#### Multiple binding and `multi-local` semantics
#### Multiple bindings and `if local` stack semantics
Multiple bindings are allowed in the same `local`-`in` clause and must be separated by commas. Like regular `local a, b = foo, bar` assignments, `bar` is not allowed to refer to the new `a` because it isn't initialized yet.
Multiple bindings are allowed in the same `local`-`in` clause and must be separated by commas. Like regular `local a, b = foo, bar` assignments, `bar` is not allowed to refer to the new `a`.
```luau
if local success, result = pcall(foo) then
@ -308,9 +207,9 @@ if local nevernil, maybenil = foo() in maybenil ~= nil then
end
```
To cleanly handle nested conditional pyramids, multiple `local`-`in` clauses may be stacked in same `if local` statement; these can be referred to as `multi-local`s, `if local` stacks, or more colloquially, `if local` pancakes.
To cleanly handle nested conditional pyramids, multiple `local`-`in` clauses may be stacked in same `if local` statement; these can be referred to as `if local` stacks, or more colloquially, `if local` pancakes.
`local`-`in` clauses in an `if local` stack must be separated from one another by whitespace or semicolon. Unlike when initializing multiple bindings in the same `local`-`in` clause, `if local` pancakes are allowed to refer to previous bindings in the stack, and this is their unique selling point and a major motivation for this RFC in general.
`local`-`in` clauses in an `if local` stack must be separated by whitespace or semicolon. Unlike when initializing multiple bindings in the same `local`-`in` clause, `if local` pancakes are allowed to refer to previous bindings in the stack, and this is their unique selling point and a major motivation for this RFC in general.
To demonstrate the utility of this, here's a simple Roblox example:
@ -324,9 +223,9 @@ then
end
```
Each `local`-`in` clause in the above `multi-local` evaluates once-at-a-time and can be thought of syntactic sugar for multiple nested `if local`s; this allows subsequent `local` bindings to refer to former ones without nesting and unnecessarily increasing cognitive complexity.
`if local` stacks can be thought of syntactic sugar for unnesting `if local`s; this allows subsequent `local` bindings to refer to former ones without unnecessarily increasing cognitive complexity.
In fact, the above code is practically equivalent to (and in an implementation, can be expanded to) the nested:
The above code is practically equivalent to (and in an implementation, can be expanded to) the nested:
```luau
if local model = hit.Parent then
@ -338,7 +237,7 @@ if local model = hit.Parent then
end
```
This makes `if local` stacks an extremely useful feature for mitigating ['pyramids of doom'](https://en.wikipedia.org/wiki/Pyramid_of_doom_(programming)) in `nil`check-heavy codebases.
This is an extremely useful feature for mitigating ['pyramids of doom'](https://en.wikipedia.org/wiki/Pyramid_of_doom_(programming)) in `nil`check-heavy codebases.
#### `if local` stack evaluation semantics
@ -363,30 +262,18 @@ end
#### Fallthrough
`if local` fallthrough (bindings in a prior branch's condition are visible in subsequent branches and their conditions) was included in and was a major motivator for the previous `if statement` initializers RFC. It was decided against due to limited utility, complicating the story of the `if local` feature, and since in other languages, it often leads to unexpected behavior, possible footguns, and is mostly only useful for error catching. Additionally, as proposed in the previous RFC, `if local` fallthrough could easily result in hard-to-understand control flow which could increase the cognitive complexity of Luau code for little benefit.
`if local` fallthrough (bindings in a prior branch's condition are visible in subsequent branches conditions and their `then` bodies) was included in and was a major motivator for the previous `if statement` initializers RFC. It was decided against due to limited utility, complicating the story of the `if local` feature, and since in other languages, it often leads to unexpected behavior, possible footguns, and is mostly only useful for error catching.
As an alternative, this RFC's `if local` pancakes provide a better way to handle stacked and dependent conditions without greatly increasing Luau's cognitive complexity.
#### Edge cases
Initializations without assignments (`if local x then end`) are not permitted and cause a syntax error. Initializations of the leftmost binding to `nil`, including but not limited to the following:
Initializations without assignments (`if local x then end` or `if local x: FooType then end`) are not permitted and cause syntax errors. Initializations of the leftmost binding to `nil`, including but not limited to the following:
- `if local x = nil then end`
- `if local x, y = nil, 3 in x == nil or y then end`
will always evaluate to `false` and will never execute a conditional branch; this means that the existing 'if condition always false' lint should be expanded to include `if local`s that never evaluate. This should reduce the likelihood of users mistakenly writing these never-evaluating `if local`s, and iron out any confusion on requiring the leftmost binding to be not-`nil`.
Type annotations may be provided alongside a `local` binding as expected:
```lua
type Cat = {
name: string,
kittens: { Cat },
}
if local cat: Cat in (cats :: { Cat? })[1] then
end
```
will always evaluate to `false` and will never execute a conditional branch; the existing 'if condition always false' lint should be expanded to include `if local`s that never evaluate. This lint should also help clear up any confusion about requiring the leftmost binding to be not-`nil`.
As an edge case, locals may be reassigned within the `in` condition. In this case, the conditional branch executes because x is initially not `nil`, allowing the `in` condition to evaluate, reassign `x` to `nil`, and return `true`:
@ -400,15 +287,15 @@ if local x: number = foo(); local y: number = (function() local y = x + 1; x = n
end
```
### `while local loops`
### `while local` loops
`while local` statements are defined as `while` loops with one or more `local` bindings. Similarly to `if local`s, each `local-in` clause must include one or more `local` bindings declared after the `while` keyword, may contain one `in` conditional clause, may be followed by other `local`-`in` clauses and must end finally with the `do` keyword.
`while local` statements are defined as `while` loops with one or more `local` bindings. Similarly to `if local`s, each `local-in` clause must include one or more `local` bindings declared after the `while` keyword, may contain one `in` conditional clause, may be followed by other `local`-`in` clauses and must be eventually followed with the `do` keyword.
```luau
while local identifier = expr() do
while local line = nextline() do
end
-- or
while local identifier = expr() in cond() do
while local text = gettext() in text ~= "" do
end
-- or
while
@ -419,22 +306,9 @@ end
-- etc.
```
`while local` identifiers are initialized and assigned once before for every iteration of the while loop, and are visible in their `in` conditions. Similarly to `if local`s, stacked `local`s in `while local`s are allowed, and iteration stops if any `in` clause evaluates falsey.
`while local` identifiers are reassigned before every iteration of the while loop and are visible in their `in` conditions and loop body. Similarly to `if local`s, stacked `local`s in `while local`s are allowed, and iteration stops if any `in` clause evaluates falsey.
Note that unlike with `if local` stacks, implementing `while local` stacks might be more complicated than just by nesting multiple control structures. We want to propose this within the RFC and let a Luau language engineer with better knowledge of the Luau (non-pancake) stack judge their viability in comparison to `if local` stacks.
```luau
while local x = nextline() in x ~= "" then
end
-- or
local contents: { string } = {}
while
local x = nextline() in x ~= ""
local content = x:match("content: ([%w%s%p]+)\n")
do
table.insert(contents, content)
end
```
> Note that unlike with `if local` stacks, implementing `while local` stacks might be more complicated than by just nesting multiple control structures. We want to propose this within the RFC and let a Luau language engineer with better knowledge of the Luau (non-pancake) stack and compiler judge their viability in comparison to `if local` stacks.
## Drawbacks / Arguments against
@ -444,7 +318,7 @@ Yes, but we want `if local` and `while local`s! They will make the language a lo
- `if local`s increase the cognitive complexity of the language and aren't enough of a value-add to implement.
While `if local`s may increase the learning burden of the language for beginners (and for existing users upon this syntax's release), they can increase the readability of Luau code, decrease the cognitive complexity of new code in Luau over time, and allow for simple and really common idioms to be expressed in a more concise way friendly for users. Additionally, `if local`s (and to a lesser extent, `while local`)s are relatively popular additions to Luau and should be received in a very friendly way by existing users.
While `if local`s may increase the learning burden of the language for beginners (and for existing users upon this syntax's release), they can increase the readability of Luau code, decrease the cognitive complexity of new code in Luau over time, and allow for simple and really common idioms to be expressed in a more concise way friendly for users.
- Adding `if local` statements without `if local` *expressions* will be confusing to users
@ -452,15 +326,17 @@ This is a viable concern, however we feel the benefits of adding `if local` stat
## Alternatives
- The leftmost binding should not be required to be non-`nil` when an `in` clause is provided.
Many alternate proposals and alternative semantics were considered for this RFC. In no particular order:
### The leftmost binding should not be required to be non-`nil` when an `in` clause is provided
With this alternative, users would have to specify `identifier and` in every case they want to use `identifier` in an `in` clause.
Since a primary motivator for `if local`s is `nil`checking, and the default behavior of `if local x = foo()` is that `x` should be non-nil, we argue that it makes more sense (and is more intuitive) for `if local`s to always assume `x` is non-nil, even when an `in` clause is provided.
- the default should be for ALL bindings to be non-`nil`, or require users write an `in` condition for `if local`s with multiple bindings within the same `local`-`in` clause.
### the default should be for ALL bindings to be non-`nil`, or require users write an `in` condition for `if local`s with multiple bindings within the same `local`-`in` clause
If all bindings were non-nil, we could hit unexpected behavior where users expect their conditions to evaluate but they never do. Additionally, it's common for `pcall` to not return a value if it succeeds.
If all bindings were non-nil, we could hit unexpected behavior where users expect their conditions to evaluate but they never do. For example, it's common for `pcall` to not return a value if it succeeds.
```luau
if local success, err = pcall(function()
@ -476,26 +352,24 @@ end
this would never evaluate the conditional branch because `err` would always be nil.
As a result of this, it's better to stick to where the first `local` cannot be nil, but others can and can be explicitly checked if desired.
Additionally we should guide users towards `if local` stacks instead of initializing multiple bindings in one `local`-`in` clause, which is more preferable than just requiring an `in` clause be present when multiple bindings are declared.
Additionally, the fact that `multi-local`s exist means that we should guide users towards `multi-local`s instead of initializing multiple bindings in one `local`-`in` clause, which is preferable than just requiring the `in` clause to be present when multiple bindings are declared.
- `if` statement initializers don't necessarily need the `local` keyword to be parseable:
### `if` statement initializers don't necessarily need the `local` keyword
```luau
if x = foo() in x and x:match("hi") then
end
```
The main reason for adopting `if local` syntax over `if identifier =` syntax is because `if local`s are more visually distinct with syntax highlighting, and therefore easier for humans to parse than `if identifier =` syntax, and because `if local`s can be considered a different user-facing feature than `if` statements, so should require a slightly different mental model.
The main reason for adopting `if local` syntax over `if identifier =` syntax is because `if local`s are more visually distinct and therefore easier for humans to parse than `if identifier =` syntax, and because `if local`s require a slightly different mental model than `if` statements. Not requiring `local` can also cause a footgun of confusion between `==` and `=` as both would be valid within an `if` condition.
A counterargument to this is that since the existing numerical loop syntax (`for i = 1, 10 do`) has an assignment without the the `local` keyword, so should `if` statement initializers to keep the language internally consistent.
We feel that the usecases sufficiently differ (`nil`checking vs numerical iteration), and that `if local` syntax is sufficiently different from numerical for loops that users will easily be able to adopt their mental models to distinguish between them and `if/while local` statements.
We feel that the usecases sufficiently differ (`nil`checking vs numerical iteration), and that `if local` syntax is sufficiently different from numerical for loops that users will easily be able to distinguish between them and `if/while local` statements.
It is notable that Rust requires `let` in both `if let` and `while let` expressions but doesn't require `let` in `for` loops, therefore having asymmetric `for` loops and `if/while`s when the latter introduces bindings isn't unheard of outside Luau.
Note that Rust requires `let` in both `if let` and `while let` expressions but doesn't require `let` in `for` loops, therefore having asymmetric `for` loops and `if/while`s syntax when the latter introduces bindings isn't unheard of outside Luau.
- Another proposed alternative was for dropping the `in` keyword for allowing the `local x = foo()` binding to be used as an expression like the walrus operator (`:=`) in Python:
### Drop the `in` keyword for allowing the `local x = foo()` binding to be used as an expression like the walrus operator (`:=`) in Python
```luau
if local a = foo() and a:match("hi") then
@ -504,11 +378,9 @@ end
The issue here is ambiguity with operator precedence. If we follow Python's implementation of the walrus, then `a` will evaluate to `foo() and a:match("hi")` (a boolean) (or break as `a` (probably `nil` unless it's a shadow) doesn't have a method `match`) instead of what the user probably intended. For this to work as intended, the `=` operator would have to bind extremely tightly to its RHS, but only in `if local`s. This would require a more complicated mental model for `if` statement initializers and would not be very user-friendly.
Additionally, Luau does not and (for now) will not support generalized bindings-in-expression syntax. Allowing `local = foo()` to be used as an expression, but only within `if` statement conditions, would certainly complicate the mental model around expressions in Luau.
Additionally, Luau does not and (for now) will not support generalized bindings-in-expression syntax. Allowing `local = foo()` to be used as an expression, but only within `if` statement conditions, would certainly complicate the mental model around expressions in Luau. Explicit `in` clauses are clearly superior to those options.
We have decided that separating the assignment expression and the evaluation expression with an `in` clause is the best way to express the logic users intend with `if local`s.
- Have `if identifier = expr()` alongside `if` and `while` locals.
### Have `if identifier = expr()` alongside `if` and `while` locals for fallthrough
In this case, `if` statement initializers would allow for fallthrough whereas `if local`s wouldn't.
@ -521,10 +393,6 @@ then
handle_plaintext(body)
elseif content_type == "application/json" then
handle_json(body)
elseif content_type == "application/octet-stream" then
handle_bytes(body)
elseif content_type == "image/png" or content_type == "image/jpeg" then
handle_image(body)
elseif local override_body = override_bodies[content_type] then
handle_custom(override_body, content_type)
else
@ -533,18 +401,16 @@ end
-- content_type not visible here
```
This would provide parity with `for i = 1, 10 do` syntax, and would appease both the fallthrough camp and the non-fallthrough camp. However, we don't see a huge reason to add a separate syntax just for fallthrough, when the primary purpose of `if local`s is for the common idiom of `nil`checking. If a user wants fallthrough, they can just define the variable above the control structure as they do currently.
This would provide parity with `for i = 1, 10 do` syntax, and would appease both the fallthrough camp and the non-fallthrough camp. However, we don't see a huge reason to add a separate syntax just for fallthrough. If a user wants fallthrough, they can just define the variable above the control structure as they do currently.
Additionally, a major usecase for `if local` fallthrough was for handling early returns by unnesting heavily-nested conditional structures, a usecase that's satisfied, in our opinion, more elegantly by `if local` stacks.
Furthermore, most usecases for fallthrough are satisfied more elegantly, in our opinion, by `if local` stacks.
## Future work
`if local` *expressions* are not formally included in this RFC due to implementation difficulty (specifically, a sizeable compiler rewrite), however are included as a future proposal and would follow extremely similar syntax to `if local` statements:
`if local` *expressions* are not formally included in this RFC due to implementation complexity (specifically, a sizeable compiler rewrite), however are included as a future proposal and would follow extremely similar syntax and semantics to `if local` statements:
```luau
local humanoid: Humanoid? = if local character = player.Character
then character:FindFirstChildOfClass("Humanoid")
else nil
```
For `if local` *expressions* to be possible, Luau would need bindings-in-expressions support, which would require a compiler rewrite.