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.
* 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>
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?
* 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 ...)
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)
It seems more consistent and unambiguous if we mark RFCs as being
implemented when the implementation lands instead of expecting to
cross-reference documentation. That also makes it easier for us to flag
stale RFCs.
