mirror of
https://github.com/luau-lang/rfcs.git
synced 2025-04-05 11:00:58 +01:00
Reworking
This commit is contained in:
Daniel P H Fox (Roblox)
parent
9354bbd4ef
commit
b4a786d8d4
GPG key ID:
B5690EEEBB952194
1 changed files with 31 additions and 244 deletions
|
|
@ -64,62 +64,49 @@ get("/users", ({
|
|||
|
||||
## Design
|
||||
|
||||
The `[]` indexing operator is extended to support explicitly reading from multiple (potentially) non-consecutive keys at once, by provided a comma-separated set of expressions.
|
||||
## Structure matcher
|
||||
|
||||
This proposal will use the term *structure matcher* to refer to syntax for retrieving values from table structures.
|
||||
|
||||
Structure matchers can appear:
|
||||
- In place of the identifiers in a `local ... = ...` declaration statement
|
||||
- In place of the identifiers in a `... = ...` assignment statement
|
||||
|
||||
A structure matcher starts with the `in` keyword, followed by braces. The keyword is necessary to avoid ambiguity on the LHS of assignments.
|
||||
|
||||
```Lua
|
||||
local numbers = {3, 5, 11}
|
||||
|
||||
local three, five, eleven = numbers[1, 2, 3]
|
||||
local in { } = data
|
||||
in { } = data
|
||||
```
|
||||
|
||||
This will desugar to this behaviour exactly:
|
||||
### Matching using dot indexing
|
||||
|
||||
Luau inherits the "dot indexing" shorthand, allowing string keys to be easily indexed:
|
||||
|
||||
```Lua
|
||||
local numbers = {3, 5, 11}
|
||||
local three, five, eleven = numbers[1], numbers[2], numbers[3]
|
||||
local foo, bar = data.foo, data.bar
|
||||
```
|
||||
|
||||
Arrays can read out an inclusive range of values from consecutively numbered keys. This is specified with `[x -> y]`, where `x` and `y` evaluate to a number.
|
||||
In structure matchers, identifiers can be specified with a dot prefix in a similar fashion.
|
||||
|
||||
The identifier acts both as the bound variable name, and as the index to use.
|
||||
|
||||
```Lua
|
||||
local numbers = {3, 5, 11}
|
||||
|
||||
local three, five, eleven = numbers[1 -> #numbers]
|
||||
local in { .foo, .bar } = data
|
||||
in { .foo, .bar } = data
|
||||
```
|
||||
|
||||
Negative numbers are allowed, with symmetric behaviour to Luau standard library functions that accept negative indices (offset from the end of the table).
|
||||
This desugars to:
|
||||
|
||||
```Lua
|
||||
local numbers = {3, 5, 11}
|
||||
|
||||
local three, five, eleven = numbers[1 -> -1]
|
||||
local foo, bar = data.foo, data.bar
|
||||
foo, bar = data.foo, data.bar
|
||||
```
|
||||
|
||||
Multiple index expressions run the risk of duplicating information already specified by the names of identifiers in declarations or re-assignments.
|
||||
|
||||
```Lua
|
||||
local nicknames = { amelia = "amy", bethany = "beth", caroline = "carol" }
|
||||
|
||||
local amelia, bethany, caroline = nicknames["amelia", "bethany", "caroline"]
|
||||
|
||||
amelia, bethany, caroline = nicknames["amelia", "bethany", "caroline"]
|
||||
```
|
||||
|
||||
If the expression appears on the right hand side of assignment to explicit identifiers, the keys may be implied to be the identifier strings.
|
||||
|
||||
```Lua
|
||||
local nicknames = { amelia = "amy", bethany = "beth", caroline = "carol" }
|
||||
|
||||
local amelia, bethany, caroline = nicknames[]
|
||||
|
||||
amelia, bethany, caroline = nicknames[]
|
||||
```
|
||||
|
||||
Implied keys do not correlate to identifier position; when positional indices are desired, use range shorthand instead.
|
||||
|
||||
## Alternatives
|
||||
|
||||
### Braces around identifier list during assignment
|
||||
### Braces around identifier list without prefix
|
||||
|
||||
The previously popular RFC used braces around the list of identifiers to signal destructuring, and dot prefixes to disambiguate array and dictionary destructuring:
|
||||
|
||||
|
|
@ -146,15 +133,6 @@ It also does not provision for destructuring in the middle of an expression, whi
|
|||
|
||||
As such, this proposal does not pursue these design directions further, as the patterns it proposes struggle to be extrapolated and repeated elsewhere in Luau.
|
||||
|
||||
There is a hypothetical way forward for this idea if the braces have a prefix.
|
||||
|
||||
```Lua
|
||||
-- One possible prefix
|
||||
local rootUtils = require("../rootUtils")
|
||||
local in { .homeDir, .workingDir } = rootUtils.rootFolders
|
||||
in { .homeDir, .workingDir } = rootUtils.rootFolders
|
||||
```
|
||||
|
||||
### Indexing assignment
|
||||
|
||||
To address the problems around assignment support, a large amount of effort was poured into finding a way of moving the destructuring syntax into the middle of the assignment.
|
||||
|
|
@ -188,189 +166,14 @@ Another exploration revolved around deciding between array/map destructuring bas
|
|||
|
||||
However, this was discarded because it made the behaviour of the assignment behave on non-local information, and was not clearly telegraphed by the syntax. It would also not work without a properly inferred type, making it unusable in the absence of type checking.
|
||||
|
||||
### Open ranges
|
||||
### Multiple indexing
|
||||
|
||||
A syntax for indexing open ranges was considered, where the start and/or end of the range would be implied to be the first/last index.
|
||||
A syntax for indexing multiple locations in a table was considered, but rejected by the Luau team over concerns it could be confused for multi-dimensional array syntax.
|
||||
|
||||
```Lua
|
||||
-- closed range
|
||||
local three, five, eleven = numbers[1 -> -1]
|
||||
local numbers = {3, 5, 11}
|
||||
|
||||
-- range with open end index
|
||||
local three, five, eleven = numbers[1 ->]
|
||||
|
||||
-- range with open start index
|
||||
local three, five, eleven = numbers[-> -1]
|
||||
|
||||
-- range wih open start & end indexes
|
||||
local three, five, eleven = numbers[->]
|
||||
```
|
||||
|
||||
This is plausible to do, and is supported by ranges in other modern programming languages:
|
||||
|
||||
``` Rust
|
||||
// closed range
|
||||
let slice = numbers[1..3]
|
||||
|
||||
// range with open end index
|
||||
let slice = numbers[1..]
|
||||
|
||||
// range with open start index
|
||||
let slice = numbers[..3]
|
||||
|
||||
// range in open start & end indexes
|
||||
let slice = numbers[..]
|
||||
```
|
||||
|
||||
This proposal does not push for open ranges so as to limit the scope of the proposal, but they are explicitly left open as a option should we wish to pursue them at a later time.
|
||||
|
||||
### Alternate range delimiters
|
||||
|
||||
This proposal selected `->` as the token to act as the range delimiter.
|
||||
|
||||
The `:` token was considered. However, this was discarded because it would be ambiguous with method call syntax.
|
||||
|
||||
```Lua
|
||||
local foo = bar[baz : garb()] -- ambiguous
|
||||
```
|
||||
|
||||
The `until` token was considered. This is not ambiguous, but was discarded for now over concerns about verbosity.
|
||||
|
||||
```Lua
|
||||
local foo = bar[1 until 3]
|
||||
```
|
||||
|
||||
The `..` token was considered. However, this was discarded because it would be ambiguous with string concatenation.
|
||||
|
||||
```Lua
|
||||
local foo = bar["hello" .. "world"] -- is this correct?
|
||||
```
|
||||
|
||||
The `...` token was considered. However, this was discarded because it would be ambiguous with a variadic multiple index.
|
||||
|
||||
```Lua
|
||||
local function foo(...)
|
||||
return bar[...] -- open range or variadic?
|
||||
end
|
||||
```
|
||||
|
||||
The `in` token was considered. However, this was discarded because it may appear misleading, sound awkward, or be incompatible with future expression syntax using `in` as an infix operator.
|
||||
|
||||
```Lua
|
||||
-- every third index?
|
||||
-- a 1/3 chance?
|
||||
-- test if 1 is found in 3?
|
||||
local three, five, eleven = numbers[1 in 3]
|
||||
```
|
||||
|
||||
A prefix `in` was also considered, but was decided against since it could be mistaken for non-range indexing.
|
||||
|
||||
```Lua
|
||||
local three, five, eleven = numbers[in 1, 3] -- in indexes 1 and 3?
|
||||
```
|
||||
|
||||
Combining `in` with another one of the tokens was considered, but it was considered too verbose to be desirable.
|
||||
|
||||
```Lua
|
||||
local foo = bar[in 1 ... 3]
|
||||
```
|
||||
|
||||
`in` also has the disadvantage of being associated with `for`, where it does not function as a range delimiter, nor a multiple indexer:
|
||||
|
||||
```Lua
|
||||
for key, value in numbers do -- `in` has a different job here
|
||||
```
|
||||
|
||||
### Don't add ranges / Don't add implicit keys
|
||||
|
||||
This proposal explicitly intends to add two shorthands:
|
||||
- Range shorthand is designed for arrays.
|
||||
- Implicit key shorthand is designed for maps.
|
||||
|
||||
This ensures both are equally easy to destructure, and that the syntax explicitly looks different for both to avoid confusion.
|
||||
|
||||
One of the previous grounds for RFC rejection was that the suggested destructuring method was asymmetric and unclear between dictionaries and arrays, and so this proposal intends to avoid that.
|
||||
|
||||
### Alternate implicit key syntax
|
||||
|
||||
An alternate `[local]` syntax was considered for implicit keys, to make it more visible after a function call:
|
||||
|
||||
```Lua
|
||||
local useState = require("@react")[local]
|
||||
```
|
||||
|
||||
There is nothing functionally wrong with this, so the proposal doesn't discard this possibility, but it was deemed to have a slightly odd shape compared to other Luau constructs. It could also have an adverse effect on line length.
|
||||
|
||||
A `local...in` syntax was considered to make the relationship between identifiers and the indexing operation clearer.
|
||||
|
||||
```Lua
|
||||
local amelia, bethany, carol in nicknames
|
||||
amelia, bethany, carol in nicknames
|
||||
```
|
||||
|
||||
This was tacitly discarded for now over concerns that the reassignment doesn't seem obvious, and may not make intuitive sense when considered together with `for..in` syntax.
|
||||
|
||||
|
||||
### Implicit key renaming
|
||||
|
||||
Renaming identifiers was considered with implicit keys, and should be possible with full backwards compatibility, and support for arbitrary expressions.
|
||||
|
||||
```Lua
|
||||
amy in "amelia", beth in "bethany", carol in "caroline" = nicknames[]
|
||||
```
|
||||
|
||||
Notably, this would allow the use of implicit keys with only some keys renamed, useful for avoiding namespace collisions:
|
||||
|
||||
```Lua
|
||||
local useEffect, useReactState in "useState", useMemo = require("@react")[]
|
||||
local useState = require("@game/reactUtils")[]
|
||||
```
|
||||
|
||||
However, it means we would need to reject this syntax for expressions without implicit keys:
|
||||
|
||||
```Lua
|
||||
local foo in "bar" = 2 + 2 -- not valid
|
||||
```
|
||||
|
||||
However, renaming is already *technically* doable via shadowing:
|
||||
|
||||
```Lua
|
||||
local useState = require("@react")[]
|
||||
local useReactState = useState
|
||||
local useState = require("@game/reactUtils")[]
|
||||
```
|
||||
|
||||
It is also possible with the explicit syntax:
|
||||
|
||||
```Lua
|
||||
local useEffect, useReactState, useMemo = require("@react")["useEffect", "useState", "useMemo"]
|
||||
local useState = require("@game/reactUtils")[]
|
||||
```
|
||||
|
||||
This proposal doesn't *reject* the idea of renaming, but considers it out of scope for now as it could potentially introduce a significant level of added complexity, and can be worked around in many ways.
|
||||
|
||||
### Implicit positional keys
|
||||
|
||||
It was considered whether to add a second "positional" implicit mode, and disambiguate between positional and identifier modes using syntax.
|
||||
|
||||
```Lua
|
||||
-- Hypothetical syntax
|
||||
amelia, bethany, caroline = nicknames[.]
|
||||
three, five, eleven = numbers[#]
|
||||
```
|
||||
|
||||
However, all syntax choices led to suboptimal outcomes, where an open range would be similarly concise, equal in functionality, and more consistent with the rest of the proposal. Not to mention, all syntax that is added is syntax that could block future RFCs.
|
||||
|
||||
As such, the proposal is fine leaving implicit keys with only one mode for simplicity, as it is wildly counterproductive to have two equally valid ways of doing the same thing.
|
||||
|
||||
```Lua
|
||||
-- As proposed (w/ open ranges)
|
||||
amelia, bethany, caroline = nicknames[]
|
||||
three, five, eleven = numbers[->]
|
||||
|
||||
-- As proposed (closed ranges only)
|
||||
amelia, bethany, caroline = nicknames[]
|
||||
three, five, eleven = numbers[1 -> -1]
|
||||
local three, five, eleven = numbers[1, 2, 3]
|
||||
```
|
||||
|
||||
### Don't do anything
|
||||
|
|
@ -379,29 +182,13 @@ This is always an option, given how much faff there has been trying to get a fea
|
|||
|
||||
However, it's clear there is widespread and loud demand for something like this, given the response to the previous RFC, and the disappointment after it was discarded at the last minute over design concerns.
|
||||
|
||||
The main argument for doing nothing is the concern over how to integrate it in a forwards-compatible and backwards-compatible way, which arises from previous RFCs focusing solely on the assignment list which is notably sensitive to ambiguity issues.
|
||||
|
||||
This proposal thus looks elsewhere in the Luau grammar, and finds other places where ambiguity is not omnipresent, so as to avoid this pitfall.
|
||||
The main argument for doing nothing is the concern over how to integrate it in a forwards-compatible and backwards-compatible way. This proposal thus looks to resolve those ambiguities in the Luau grammar so as to avoid this pitfall.
|
||||
|
||||
## Drawbacks
|
||||
|
||||
### Array/map distinction
|
||||
### Use of `in` keyword as infix operator
|
||||
|
||||
A common sticking point in previous destructuring designs has been how to disambiguate array destructuring from map destructuring.
|
||||
|
||||
This proposal attempts to solve this functionally by introducing two syntaxes, one for each:
|
||||
|
||||
```Lua
|
||||
-- As proposed (w/ open ranges)
|
||||
amelia, bethany, caroline = nicknames[]
|
||||
three, five, eleven = numbers[->]
|
||||
|
||||
-- As proposed (closed ranges only)
|
||||
amelia, bethany, caroline = nicknames[]
|
||||
three, five, eleven = numbers[1 -> -1]
|
||||
```
|
||||
|
||||
While not strictly as intuitive as the design of previous RFCs, it solves every hard design problem nicely. That said, the proposal is still open to evolving this syntax based on feedback if the distinction is deemed unclear.
|
||||
By allowing `in` at the start of a statement, we preclude the use of `in` as an infix operator at any point in the future. There have been some discussions about a similar operator in the past, but they have not seen any clear support, so this proposal decided to use this keyword.
|
||||
|
||||
### Roblox - Property casing
|
||||
Today in Roblox, every index doubly works with camel case, such as `part.position` being equivalent to `part.Position`. This use is considered deprecated and frowned upon. However, even with variable renaming, this becomes significantly more appealing. For example, it is common you will only want a few pieces of information from a `RaycastResult`, so you might be tempted to write:
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue