RFC: Singleton types #37
Conversation
I don't think this works because of hash collisions. I suspect we would have to use a full string representation atm, since our type checker lacks cross-module interned strings. |
|
Yeah I suppose the point of it is to show that it's possible to not increase the time complexity when comparing strings in the type checker. Pointer address is certainly the most robust strategy one can take. You're right that the best way to implement this is to follow same direction we took for AstLocals, but with global interning support. I'll update the proposal in a way that talks about the time complexity being a non-issue, but without any concrete implementation detail. |
Reword to exclude O(1) claims
- Improve error recovery during type checking - Initial (not fully complete) implementation for singleton types (RFC RFC: Singleton types #37) - Implement a C-friendly interface for compiler (luacode.h) - Remove C++ features from lua.h (removed default arguments from luau_load and lua_pushcfunction) - Fix lua_breakpoint behavior when enabled=false - Implement coroutine.close (RFC RFC: coroutine.close #88) Note, this introduces small breaking changes in lua.h: - luau_load env argument is now required, pass an extra 0 - lua_pushcfunction now must be called with 3 arguments; if you were calling it with 2 arguments, pass an extra NULL; if you were calling it with 4, use lua_pushcclosure. These changes are necessary to make sure lua.h can be used from pure C - the future release will make it possible by adding an option to luaconf.h to change function name mangling to be C-compatible. We don't anticipate breaking the FFI interface in the future, but this change was necessary to restore C compatibility. Closes #121 Fixes #213
No description provided.