Update compatibility.md (#559)

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 |
+| 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 |
+| 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 |
@@ -95,16 +95,16 @@ Ephemeron tables may be implemented at some point since they do have valid uses
 
 It's important to highlight integer support and bitwise operators. For Luau, it's rare that a full 64-bit integer type is necessary - double-precision types support integers up to 2^53 (in Lua which is used in embedded space, integers may be more appealing in environments without a native 64-bit FPU). However, there's a *lot* of value in having a single number type, both from performance perspective and for consistency. Notably, Lua doesn't handle integer overflow properly, so using integers also carries compatibility implications.
 
-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.
+If integers are taken out of the equation, bitwise operators make less sense, as integers aren't a first class feature; 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. Common arguments for this include a more familiar syntax, which, while true, gets more nuanced as `^` isn't available as a xor operator, and arithmetic right shift isn't expressible without yet another operator, and performance, which in Luau is substantially better than in Lua because `bit32` library uses VM builtins instead of expensive function calls.
 
-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, or by freezing table values and thus guaranteeing immutability.
 
 ## Differences from Lua