Update compatibility.md

docs/_pages/compatibility.md

@@ -49,20 +49,20 @@ Sandboxing challenges are [covered in the dedicated section](sandbox).
 |---------|--------|------|
 | yieldable pcall/xpcall | ✔️ | |
 | yieldable metamethods | ❌ | significant performance implications |
-| ephemeron tables | ❌ | this complicates the garbage collector esp. for large weak tables |
-| emergency garbage collector | ❌ | Luau runs in environments where handling memory exhaustion in emergency situations is not tenable |
+| ephemeron tables | ❌ | this complicates and slows down the garbage collector esp. for large weak tables |
+| emergency garbage collector | 🤷‍ | Luau runs in environments where handling memory exhaustion in emergency situations is not tenable |
 | goto statement | ❌ | this complicates the compiler, makes control flow unstructured and doesn't address a significant need |
 | finalizers for tables | ❌ | no `__gc` support due to sandboxing and performance/complexity |
 | no more fenv for threads or functions | 😞 | we love this, but it breaks compatibility |
 | tables honor the `__len` metamethod | 🤷‍♀️ | performance implications, no strong use cases
 | hex and `\z` escapes in strings | ✔️ | |
 | support for hexadecimal floats | 🤷‍♀️ | no strong use cases |
-| order metamethods work for different types | ❌ | no strong use cases and more complicated semantics + compat |
+| order metamethods work for different types | ❌ | no strong use cases and more complicated semantics, compatibility and performance implications |
 | empty statement | 🤷‍♀️ | less useful in Lua than in JS/C#/C/C++ |
-| `break` statement may appear in the middle of a block | 🤷‍♀️ | we'd like to do it for return/continue as well but there be dragons |
+| `break` statement may appear in the middle of a block | 🤷‍♀️ | we'd like to do it consistently for `break`/`return`/`continue` but there be dragons |
 | arguments for function called through `xpcall` | ✔️ | |
 | optional base in `math.log` | ✔️ | |
-| optional separator in `string.rep` | 🤷‍♀️ | no real use cases |
+| optional separator in `string.rep` | 🤷‍♀️ | no strong use cases |
 | new metamethods `__pairs` and `__ipairs` | ❌ | superseded by `__iter` |
 | frontier patterns | ✔️ | |
 | `%g` in patterns | ✔️ | |
@@ -83,7 +83,7 @@ Ephemeron tables may be implemented at some point since they do have valid uses
 |---------|--------|------|
 | `\u` escapes in strings | ✔️ | |
 | integers (64-bit by default) | ❌ | backwards compatibility and performance implications |
-| bitwise operators | ❌ | `bit32` library covers this |
+| bitwise operators | ❌ | `bit32` library covers this in absence of 64-bit integers |
 | basic utf-8 support | ✔️ | we include `utf8` library and other UTF8 features |
 | functions for packing and unpacking values (string.pack/unpack/packsize) | ✔️ | |
 | floor division | ❌ | no strong use cases, syntax overlaps with C comments |
@@ -97,14 +97,14 @@ It's important to highlight integer support and bitwise operators. For Luau, it'
 
 If integers are taken out of the equation, bitwise operators make much less sense; additionally, `bit32` library is more fully featured (includes commonly used operations such as rotates and arithmetic shift; bit extraction/replacement is also more readable). Adding operators along with metamethods for all of them increases complexity, which means this feature isn't worth it on the balance.
 
-Floor division is less harmful, but it's used rarely enough that `math.floor(a/b)` seems like an adequate replacement; additionally, `//` is a comment in C-derived languages and we may decide to adopt it in addition to `--` at some point.
+Floor division is much less complex, but it's used rarely enough that `math.floor(a/b)` seems like an adequate replacement; additionally, `//` is a comment in C-derived languages and we may decide to adopt it in addition to `--` at some point.
 
 ## Lua 5.4
 
 | feature | status | notes |
 |--|--|--|
 | new generational mode for garbage collection | 🔜 | we're working on gc optimizations and generational mode is on our radar
-| to-be-closed variables | ❌ | the syntax is ugly and inconsistent with how we'd like to do attributes long-term; no strong use cases in our domain |
+| to-be-closed variables | ❌ | the syntax is inconsistent with how we'd like to do attributes long-term; no strong use cases in our domain |
 | const variables | ❌ | while there's some demand for const variables, we'd never adopt this syntax |
 | new implementation for math.random | ✔️ | our RNG is based on PCG, unlike Lua 5.4 which uses Xoroshiro |
 | optional `init` argument to `string.gmatch` | 🤷‍♀️ | no strong use cases |
@@ -112,14 +112,14 @@ Floor division is less harmful, but it's used rarely enough that `math.floor(a/b
 | coercions string-to-number moved to the string library | 😞 | we love this, but it breaks compatibility |
 | new format `%p` in `string.format` | 🤷‍♀️ | no strong use cases |
 | `utf8` library accepts codepoints up to 2^31 | 🤷‍♀️ | no strong use cases |
-| The use of the `__lt` metamethod to emulate `__le` has been removed | 😞 | breaks compatibility and doesn't seem very interesting otherwise |
+| The use of the `__lt` metamethod to emulate `__le` has been removed | ❌ | breaks compatibility and complicates comparison overloading story |
 | When finalizing objects, Lua will call `__gc` metamethods that are not functions | ❌ | no `__gc` support due to sandboxing and performance/complexity |
 | The function print calls `__tostring` instead of tostring to format its arguments. | ✔️ | |
 | By default, the decoding functions in the utf8 library do not accept surrogates. | 😞 | breaks compatibility and doesn't seem very interesting otherwise |
 
-Lua has a beautiful syntax and frankly we're disappointed in the `<const>`/`<close>` which takes away from that beauty. Taking syntax aside, `<close>` isn't very useful in Luau - its dominant use case is for code that works with external resources like files or sockets, but we don't provide such APIs - and has a very large complexity cost, evidences by a lot of bug fixes since the initial implementation in 5.4 work versions. `<const>` in Luau doesn't matter for performance - our multi-pass compiler is already able to analyze the usage of the variable to know if it's modified or not and extract all performance gains from it - so the only use here is for code readability, where the `<const>` syntax is... suboptimal.
+Taking syntax aside (which doesn't feel idiomatic or beautiful), `<close>` isn't very useful in Luau - its dominant use case is for code that works with external resources like files or sockets, but we don't provide such APIs - and has a very large complexity cost, evidences by a lot of bug fixes since the initial implementation in 5.4 work versions. `<const>` in Luau doesn't matter for performance - our multi-pass compiler is already able to analyze the usage of the variable to know if it's modified or not and extract all performance gains from it - so the only use here is for code readability, where the `<const>` syntax is... suboptimal.
 
-If we do end up introducing const variables, it would be through a `const var = value` syntax, which is backwards compatible through a context-sensitive keyword similar to `type`.
+If we do end up introducing const variables, it would be through a `const var = value` syntax, which is backwards compatible through a context-sensitive keyword similar to `type`. That said, there's ambiguity wrt whether `const` should simply behave like a read-only variable, ala JavaScript, or if it should represent a stronger contract, for example by limiting the expressions on the right hand side to ones compiler can evaluate ahead of time to improve performance.
 
 ## Differences from Lua