This function might be of particular use if #739 is accepted, but as it
stands, it still brings a measurable reduction in complexity for
swapping byte order and is measurably faster (around a 50% reduction in
time per operation on my machine), albeit on the order of magnitude of
nanoseconds.
String interpolation and table.getn/et al deprecation has been live for
a while.
getfenv/setfenv linter diagnostics is going to ship in the next release,
so preemptively marking this as Implemented as well.
It looks like all three functions actually have been deprecated in Lua
5.1, and removed in Lua 5.2.
We do not plan to remove them to retain backwards compatibility, but the
RFC should be more precise.
We've had this restriction in the original RFC, but decided to remove it afterwards. This change puts the restriction back - we need to work through some implications of future support for string-based DSLs together with interpolated strings which may or may not change the behavior here, for example to allow something like
```
local fragment = xml `
<img src="{self.url}" />
`
```
This was implicitly assumed to be supported, but we should really just say so explicitly. If we didn't, there'd be two ways to interpret it: string interpolations are raw strings and escape sequences don't exist for the most part (false), or string interpolations are like strings and escape sequences do exist (true).
Also talks about the ambiguity with `\u{` and that it is defined to take priority and does not terminate the interpolation chunk and starts a new expression, instead it must be a well-formed escape sequence `\u{...}`. It is very unlikely there'd be another escape sequence that also has this same ambiguity problem, so we don't need to worry about this.
We make four adjustments in this RFC:
1. `{{` is not allowed. This is likely a valid but poor attempt at escaping coming from C#, Rust, or Python.
2. We now allow `` `this` `` with zero interpolating expressions.
3. We now allow `` f `this` `` also.
4. Explicitly say that `` `this` `` and `` `this {that}` `` are not valid type annotation syntax.
When considering new standard library functions, we essentially need to strongly justify their existence over their implementation in Luau in user library code.
This PR attempts to provide a few axes of consideration; ideally new library functions tick many of the boxes, eg "used often + is more performant + clear unambiguous interface" is an ideal consideration for a library function, whereas if it's merely accelerating a single specific use case for a single application it's unlikely to be a good justification for inclusion.
This meta-RFC proposes removing the previously accepted RFC on safe navigation operator. This is probably going to be disappointing but is the best course of action that reflects our ideals in language evolution.
See PR thread for rationale and discussion.
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.
