* Create require-by-string-aliases.md
* Update require-by-string-aliases.md
* Update require-by-string-aliases.md
* Changed aliases to be case-insensitive + restricted the charset
* Update docs/require-by-string-aliases.md
Co-authored-by: Alexander McCord <11488393+alexmccord@users.noreply.github.com>
* Update require-by-string-aliases.md to have @
* Include justification for alias name case insensitivity
* Fixed typo
* Removed duplicate section
---------
Co-authored-by: Alexander McCord <11488393+alexmccord@users.noreply.github.com>
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.
