luau-lang/luau
1
0
Fork 0
mirror of https://github.com/luau-lang/luau.git synced 2025-05-04 10:33:46 +01:00
Code Issues Projects Releases Packages Wiki Activity
464 commits 4 branches 167 tags 51 MiB
Commit graph

63 commits

Author SHA1 Message Date
Arseny Kapoulkine
1c6a7e61a6
RFC: Do not implement safe navigation operator 
This meta-RFC proposes removing the previously accepted RFC on safe navigation operator. This is probably going to be disappointing but I feel like this is the best course of action that reflects our ideals in language evolution.

## Problem

The RFC specifies a new navigation operator, `?.`, that returns `nil` when the left hand side is `nil`, as well as skipping the rest of the indexed chain evaluation (e.g. `vehicle.Turret?.Frame.CFrame.LookVector` evaluates to `nil` if `vehicle.Turret` is `nil`). Initially the RFC only specifies this one operator, although future extensions like `?:`, `?[]`, `?()` are possible -- the RFC stands on its own, but it opens the path to more "nil-safe" operators in the future.

Unfortunately, we discovered a significant problem (after the RFC was merged) in the operator, in its interaction with the Roblox instance hierarchy. This is a userdata based DOM tree that (unfortunately) overloads __index to access children, and (fortunately?) attempting to access a non-existent child raises an error. As such, it's not compatible with this proposal in the sense that trying to use `?.` in combination with the instance hierarchy will only work if the child is present, and will raise an error otherwise.

## Alternatives

There are several ways to address that problem and still ship this; all of them are unsatisfactory:

1. We can change the instance hierarchy at Roblox to return `nil` instead. If Luau existed 15 years ago with `?.` feature, we probably would not have implemented dot-access in the first place, or maybe had it return `nil`... However, at present this is a very significant change that very dramatically changes the contract around instance access and may have large unintended consequences. It's something that isn't obviously a good idea in the first place, and not something we'd want to do for a single language feature as other features may pull us into maintaining the status quo instead.

2. We can ignore this footgun and/or try to help with static analysis. The issue here is that static analysis must depend on us knowing the precise type and tree location of the first object in the chain, something that will very often not work reliably, and the pattern is too convenient and too common - so we should probably admit that with or without analysis, people will be hitting this often accidentally. This can be treated as a reasonable compromise - we're adding a convenient feature that requires a little care around some constructs, and as long as the users "know what they are doing" it's going to be okay - but my perspective is that we should try to keep the language as free of footguns / as orthogonal / as simple as possible, and any feature that has significant issues around these must be a critical feature we can't live without for us to tolerate these.

3. We can introduce a new metamethod, `__safeindex`, that will be called for `?.` instead of `__index`, if present. This metamethod can then be defined for Roblox instance hierarchy to return `nil`. My perspective here is that while it removes the footgun, it violates the orthogonality / simplicity of the null safety operators in general - just for this one operator it now requires new VM opcodes, new table lookup functions that use either `__safeindex` or `__index` metamethods, and creates questions for any future null safety operators wrt whether or not we will go through the same process for consistency (eventually yielding `__safecall`, `__safenewindex`, `__safeadd` etc. in the extreme), or if `__safeindex` is a one-off ad hoc addition to solve a specific problem we have for one of the (well, largest) users of Luau language. This turns the safe navigation operator from "cheap convenient syntax sugar" to "full blown operator every element of the stack must be aware of", which - again, in my perspective - shifts the balance for this feature, as the costs no longer seem to justify the benefit.

## Conclusion

While we have ways forward for this proposal, they either make the language less robust [when used in Roblox environment], mean this feature is much less orthogonal/simple than initially understood, or mean we need to dramatically change the access rules [in Roblox environment] for a single small language feature.

While it's unusual to judge a feature of a general purpose language based on a single user of the said language, given Luau's heritage and the fact that the majority of the programmers who interact with Luau presently use it in context of Roblox, I think we must take this into account. These situations will probably happen rarely - in fact it's the first feature proposal like this! - but when they do, we should strive to keep the language simple and devoid of footguns, thus I believe it's overall beneficial to maintain the status quo and not implement this proposal.

As suggested in the RFC, this still means you can use `and` operator as a replacement for very basic single-element chains, e.g. `dog and dog.name`, but for more complex chains with `nil`s unfortunately the existing longer patterns must be used. We plan to look into common subexpression elimination that, under certain conditions, will allow us to maximally efficiently evaluate seemingly redundant expressions like `foo and foo.bar and foo.bar.baz`, and if that doesn't work you'd need to settle for multiple expressions to evaluate these chains efficiently in presence of nils - that said, I think in this case shorter code for some cases like this is not a strong enough motivation to ship the feature in the face of the problem discussed above.

cc @Kampfkarren for visibility
 2022-05-24 16:31:04 -07:00
Arseny Kapoulkine
87fe15ac51
Update STATUS.md 
Mark last table subtyping RFC as implemented
 2022-05-12 10:08:36 -07:00
Arseny Kapoulkine
a775e6dc8e
Mark last table subtyping RFC as implemented 2022-05-12 10:08:10 -07:00
Arseny Kapoulkine
105e74c7d9
Update STATUS.md 
Both generalized iteration and LBC are implemented but not fully enabled in Roblox yet.
 2022-05-11 15:14:51 -07:00
Arseny Kapoulkine
af64680a5e
Mark singleton types and unsealed table literals RFCs as implemented (#438) 2022-03-29 16:58:59 -07:00
Andy Friesen
75bccce3db
RFC: Lower Bounds Calculation (#388) 
Co-authored-by: vegorov-rbx <75688451+vegorov-rbx@users.noreply.github.com>
 2022-03-29 12:37:14 -07:00
Arseny Kapoulkine
5e7e462104
Update STATUS.md 2022-03-24 13:10:56 -07:00
Arseny Kapoulkine
ab64a097cd
Mark sealed table subtyping RFC as implemented 2022-03-24 13:10:30 -07:00
Arseny Kapoulkine
b8e025311b
Mark table.clone as implemented 2022-03-24 09:29:20 -07:00
Arseny Kapoulkine
5a21c41363
Update STATUS.md 2022-03-24 09:26:42 -07:00
Alexander McCord
7ab76e582c
RFC: Do not implement non-nil postfix ! operator. (#420) 
This is a meta-RFC. I'd like to propose to remove the postfix `!` operator from the language.

I'd like to argue that this operator will eventually become useless and can only be used incorrectly at some point in the future, and that there are likely ways for them to be sound without having to reach for the `!` hammer.

With that, I present these counterarguments:

Shortcoming <span>#</span>1: Refinements does not apply to the block after `return`/`break`/`continue`.

```lua
if not x or not y then return end
-- both x and y are truthy
```

This will be solved by implementing control flow analysis where it'd apply the inverse of the condition leading up to the control transfer statement to the rest of the scope.

Shortcoming <span>#</span>2: Type checker is not aware of the actual state of various locations.

```lua
type Foo = { x: { y: number }? }?
local foo: Foo = { x = { y = 5 } }
print(foo.x.y) -- prints 5 at runtime, type checker warns on this
```

This will be solved by implementing type states where it would inspect the initialization sites as well as assignments to know their actual states. That is, rather than trusting the type annotation `Foo` as the state which gets us far enough, we'd start seeing these type annotations as a subtype constraint for the location `foo`.

---

If there are other use cases not covered in this message, we should talk about that and see if there exists an alternative direction that can solve these use cases soundly.
 2022-03-24 08:38:16 -07:00
Alexander McCord
2f15079642
Fold in rationale for making else branch mandatory in if-then-else expressions. (#426) 
This has been discussed but just didn't get incorporated into the RFC.
 2022-03-23 16:53:52 -07:00
Arseny Kapoulkine
898c0501d1
Update STATUS.md 
Add table.clone
 2022-02-28 14:16:35 -08:00
Arseny Kapoulkine
5e8242aeda
RFC: table.clone (#362) 2022-02-28 14:15:33 -08:00
Arseny Kapoulkine
3c42b3a013
Revert "Mark singleton types RFC as implemented (#370)" (#378) 
This reverts commit 731e197757.
 2022-02-19 10:57:29 -08:00
Alexander McCord
731e197757
Mark singleton types RFC as implemented (#370) 2022-02-17 16:16:31 -08:00
Arseny Kapoulkine
e49a0fd4cd
Mark default type parameters RFC as implemented (#369) 2022-02-17 16:14:35 -08:00
Arseny Kapoulkine
e541e19f44
Create RFC status tracking document (#363) 
This tracks status of all unimplemented RFCs in one central place. Hopefully we won't forget to update this when new RFCs are added!
 2022-02-15 18:37:02 -08:00
Arseny Kapoulkine
7d679b317f
RFC: Generalized iteration (#335) 
Co-authored-by: dcope-rbx <91100513+dcope-rbx@users.noreply.github.com>
Co-authored-by: vegorov-rbx <75688451+vegorov-rbx@users.noreply.github.com>
 2022-02-14 10:04:07 -08:00
Arseny Kapoulkine
a23b467485
Add turbofish discussion to generic function RFC (#300) 2022-01-07 11:07:36 -08:00
Arseny Kapoulkine
287b46e6a7
Mark bidirectional ascription RFC as implemented (#305) 2022-01-07 11:07:22 -08:00
Arseny Kapoulkine
b5e338325b
Mark coroutine.close RFC as implemented (#304) 2022-01-07 08:52:33 -08:00
Alan Jeffrey
82587bef29
RFC: Fix an unsoundness issue around stripping optional properties (#276) 
* Fix an unsoundness issue around stripping optional properties

Co-authored-by: vegorov-rbx <75688451+vegorov-rbx@users.noreply.github.com>
 2022-01-06 12:48:09 -06:00
boyned//Kampfkarren
5e7648947b
RFC: Safe navigation operator (#142) 
Co-authored-by: Alexander McCord <11488393+alexmccord@users.noreply.github.com>
 2021-12-20 15:38:15 -08:00
vegorov-rbx
71adace16e
RFC: Amend 'Default type alias type parameters' for type pack parameters (#238) 
* Do not allow regular type assignment to a type pack as a default parameter

* With type pack support in type aliases, this second form with an empty list is now supported

* Update rfcs/syntax-default-type-alias-type-parameters.md

Co-authored-by: Alan Jeffrey <403333+asajeffrey@users.noreply.github.com>

* Update syntax-default-type-alias-type-parameters.md

Even more examples

Co-authored-by: Alan Jeffrey <403333+asajeffrey@users.noreply.github.com>
 2021-12-08 04:21:47 -08:00
Arseny Kapoulkine
9488f2379d
Mark bit32.count* RFC as implemented 2021-12-03 11:10:41 -08:00
vegorov-rbx
6b2b179aa6
Mark 'Type alias type packs' RFC as implemented (#237) 2021-11-23 10:03:20 -08:00
Alexander McCord
6958716ccd
RFC: String interpolation (#165) 2021-11-22 14:59:38 -08:00
Arseny Kapoulkine
4265e58ad1
RFC: coroutine.close (#88) 2021-11-17 06:49:49 -08:00
Alan Jeffrey
59366ad7f8
Clarified parsing properties of tables in the presence of singleton types (#207) 2021-11-16 14:48:01 -06:00
Arseny Kapoulkine
70ffc8a01d
RFC: Do not allow method call on string literals (#145) 2021-11-12 06:54:00 -08:00
Arseny Kapoulkine
fe1bf43b54
RFC: bit32.countlz/countrz (#89) 
Co-authored-by: vegorov-rbx <75688451+vegorov-rbx@users.noreply.github.com>
 2021-11-09 10:40:14 -08:00
Josh Soref
278e848cc2
Spelling (#119) 
Fixed various spelling errors.

Co-authored-by: Josh Soref <jsoref@users.noreply.github.com>
 2021-11-04 09:50:46 -05:00
Arseny Kapoulkine
1f0084daa3 Mark RFCs that were implemented as such. 2021-11-03 21:35:25 -07:00
Amber's Careware
eed3c8c38f
Update config-luaurc.md (#104) 
When running `luau-analyze` with a .luarc that has a "mode" key, it outputs the following:
> .luaurc: Unknown key mode
I'm assuming it was named "mode" at first and was re-named "languageMode" later on?
 2021-11-03 13:15:51 -07:00
Arseny Kapoulkine
05a41d5d54
Remove team restriction from RFC process documentation 
Fixes #98
 2021-11-03 12:13:42 -07:00
vegorov-rbx
0fd38fd765
RFC: Type alias type packs (#83) 2021-10-27 11:53:45 -07:00
Alan Jeffrey
59c0492419
RFC: Write-only properties (#79) 
Co-authored-by: vegorov-rbx <75688451+vegorov-rbx@users.noreply.github.com>
 2021-10-27 11:42:17 -07:00
Alan Jeffrey
628d7d9fcd
RFC: Read-only properties (#77) 
* Added rfcs/property-readonly.md

Co-authored-by: vegorov-rbx <75688451+vegorov-rbx@users.noreply.github.com>
 2021-10-11 09:58:01 -05:00
Arseny Kapoulkine
d42dba9c95
RFC: Configure analysis via .luaurc (#47) 2021-10-07 22:41:56 -07:00
Arseny Kapoulkine
c54a8c81f6
Update function-table-freeze.md 
Fix typos and formatting
 2021-10-07 17:51:08 -07:00
Alan Jeffrey
f8fb1016dc
RFC: Unsealed table assignment creates an optional property (#73) 
* Added rfcs/unsealed-table-assign-optional-property.md

Co-authored-by: Lily Brown <lily@lily.fyi>
 2021-10-05 19:22:38 -05:00
Alan Jeffrey
43b803b267
RFC: Recursive type restriction (#68) 
Co-authored-by: Alan Jeffrey <403333+asajeffrey@users.noreply.github.com>
Co-authored-by: vegorov-rbx <75688451+vegorov-rbx@users.noreply.github.com>
 2021-09-27 10:49:03 -07:00
Arseny Kapoulkine
08bdb5b202
Rename syntax-type-ascription-2.md to syntax-type-ascription-bidi.md 2021-09-23 11:18:02 -07:00
Arseny Kapoulkine
1788de56a0
Update syntax-if-expression.md 
Add a note that only one expression is evaluated in `if-expr`.
 2021-09-22 14:08:37 -07:00
Andy Friesen
d35b2a65c9
RFC: Update type assertions to permit conversion between any two related types (#56) 
Co-authored-by: Arseny Kapoulkine <arseny.kapoulkine@gmail.com>
 2021-09-14 11:55:20 -07:00
vegorov-rbx
10a407226b
RFC: Default type alias type parameters (#61) 
* RFC: Default type alias type parameters

* Update the motivating example to match actual motivating example

* Resolved review comments

* improved motivation for the feature and noted additional languages with this feature
* fixed terminology between 'argument' and 'parameter'
* brought back support for default type pack parameter values
* removed alternative syntax and described the decision between ':' and '=' in the design section
* fixed drawback text and provided an example

* Remove return type pack annotation from allowed type pack default values,type annotation syntax doesn't allow that to be stand-alone

* Generic type pack has to be referenced by generic type pack name (with ...)
 2021-08-20 20:26:37 +03:00
Arseny Kapoulkine
7e71295c27
RFC: Deprecate getfenv/setfenv (#51) 2021-06-24 23:02:57 -07:00
vegorov-rbx
9a4487f3e9
RFC: nil-forgiving operator (#48) 
Co-authored-by: Alexander McCord <11488393+alexmccord@users.noreply.github.com>
 2021-06-23 12:58:00 -07:00
Arseny Kapoulkine
e8a58ea42f
Update if-expr RFC with mid-block return interaction (#43) 
We don't have mid-block return support yet and it's not clear if we will due to similar grammatical issues with this wrt function calls, but noting this for completeness (thanks @alexmccord for bringing this up)
 2021-06-01 15:45:43 -07:00