Update compatibility.md (#2)

This reflects the code changes we've made to upgrade string library:

- Updated the match implementation to 5.2, adding support for `%g` and `\0` in patterns
- Added string pack/unpack from 5.3
This commit is contained in:
Arseny Kapoulkine 2020-07-24 11:10:59 -07:00 committed by GitHub
parent 6163ac78b5
commit ac53e4efc0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 3 deletions

View File

@ -60,8 +60,8 @@ Sandboxing challenges are [covered in the dedicated section](sandbox.md).
| optional separator in `string.rep` | 🤷‍♀️ | no real use cases | | optional separator in `string.rep` | 🤷‍♀️ | no real use cases |
| new metamethods `__pairs` and `__ipairs` | ❌ | would like to reevaluate iteration design long term | | new metamethods `__pairs` and `__ipairs` | ❌ | would like to reevaluate iteration design long term |
| frontier patterns | ✔️ | | | frontier patterns | ✔️ | |
| `%g` in patterns | 🤷‍♀️ | no strong use cases but no major implications | | `%g` in patterns | ✔️ | |
| `\0` in patterns | 🤷‍♀️ | no strong use cases but no major implications | | `\0` in patterns | ✔️ | |
| `bit32` library | ✔️ | | | `bit32` library | ✔️ | |
Two things that are important to call out here are various new metamethods for tables and yielding in metamethods. In both cases, there are performance implications to supporting this - our implementation is *very* highly tuned for performance, so any changes that affect the core fundamentals of how Lua works have a price. To support yielding in metamethods we'd need to make the core of the VM more involved, since almost every single "interesting" opcode would need to learn how to be resumable - which also complicates future JIT/AOT story. Metamethods in general are important for extensibility, but very challenging to deal with in implementation, so we err on the side of not supporting any new metamethods unless a strong need arises. Two things that are important to call out here are various new metamethods for tables and yielding in metamethods. In both cases, there are performance implications to supporting this - our implementation is *very* highly tuned for performance, so any changes that affect the core fundamentals of how Lua works have a price. To support yielding in metamethods we'd need to make the core of the VM more involved, since almost every single "interesting" opcode would need to learn how to be resumable - which also complicates future JIT/AOT story. Metamethods in general are important for extensibility, but very challenging to deal with in implementation, so we err on the side of not supporting any new metamethods unless a strong need arises.
@ -78,7 +78,7 @@ Ephemeron tables may be implemented at some point since they do have valid uses
| integers (64-bit by default) | ❌ | backwards compatibility and performance implications | | integers (64-bit by default) | ❌ | backwards compatibility and performance implications |
| bitwise operators | ❌ | `bit32` library covers this | | bitwise operators | ❌ | `bit32` library covers this |
| basic utf-8 support | ✔️ | we include `utf8` library and other UTF8 features | | basic utf-8 support | ✔️ | we include `utf8` library and other UTF8 features |
| functions for packing and unpacking values (string.pack/unpack/packsize) | 🔜 | very useful for working with binary data | | functions for packing and unpacking values (string.pack/unpack/packsize) | ✔️ | |
| floor division | ❌ | no strong use cases, syntax overlaps with C comments | | floor division | ❌ | no strong use cases, syntax overlaps with C comments |
| `ipairs` and the `table` library respect metamethods | ❌ | no strong use cases, performance implications | | `ipairs` and the `table` library respect metamethods | ❌ | no strong use cases, performance implications |
| new function `table.move` | ✔️ | | | new function `table.move` | ✔️ | |