Any hope for enabling DLUAJIT_ENABLE_LUA52COMPAT for LuaJit?

[nomoon]

Hi,

At least the last version I used, the functionality of Lua 5.2 with regards to the __pairs and __ipairs metatable methods (available in LuaJit with DLUAJIT_ENABLE_LUA52COMPAT enabled) was missing. There aren't very many backwards-incompatible issues with this flag, and several unique and useful sets of functionality. Any chance we'll see it by default in a future love release (or did I miss it in the latest one)?

[Karai17]

What are the issues and benefits?

[zorg]

These:

Other features are only enabled, if LuaJIT is built with -DLUAJIT_ENABLE_LUA52COMPAT:
goto is a keyword and not a valid variable name anymore.
break can be placed anywhere. Empty statements (;;) are allowed.
__lt, __le are invoked for mixed types.
__len for tables. rawlen() library function.
pairs() and ipairs() check for __pairs and __ipairs.
coroutine.running() returns two results.
table.pack() and table.unpack() (same as unpack()).
io.write() and file:write() return file handle instead of true.
os.execute() and pipe:close() return detailed exit status.
debug.setmetatable() returns object.
debug.getuservalue() and debug.setuservalue().
Remove math.mod(), string.gfind().
Note: this provides only partial compatibility with Lua 5.2 at the language and Lua library level. LuaJIT is API+ABI-compatible with Lua 5.1, which prevents implementing features that would otherwise break the Lua/C API and ABI (e.g. _ENV).

So it may break goto usage as varnames, coroutine.running (though only if the result order was modified as well), potentially os.execute, math.mod (should use % anyway) and string.gfind.... though if luaJIT decides to go a different route, saying these won't be supported in the future, enabling them at any point will be more problematic than never having enabled it in the first place... imo.

[Karai17]

While those additions and changes seem acceptable, I don't know if compiling love with non-standard flags would be the best idea. People have come to expect LuaJIT to behave a certain way. If LuaJIT 2.1 decised to add these changes to the main system, then so be it. but as a compile time flag? Maybe we should hold off.

Of course, you are able to compile love yourself with that flag set and release your game fused so it runs on your own binary instead of a system binary.

[slime]

While those additions and changes seem acceptable, I don't know if compiling love with non-standard flags would be the best idea. People have come to expect LuaJIT to behave a certain way.

Yep. You don't even necessarily need to recompile LÖVE in order to swap out Lua/LuaJIT implementations as well.

[nomoon]

The biggest ones for me are the additional metamethods on tables (__pairs, __len, __ipairs in particular).

I've tried to compile Mac and Windows versions of Love2d myself with the settings, but come up short. I do a fair amount of non-Lua programming, but compiling lua as a framework to replace the ones provided by the compilation instructions (mac), and figuring out the maze of CMake and additional library stuff (windows) had me pretty stumped.

[nomoon]

While those additions and changes seem acceptable, I don't know if compiling love with non-standard flags would be the best idea. People have come to expect LuaJIT to behave a certain way. If LuaJIT 2.1 decised to add these changes to the main system, then so be it. but as a compile time flag? Maybe we should hold off.

LuaJIT is more or less in stasis as "Lua 5.1 compatible by default" and these 5.2 optional features are likely the only additional ones to be added (according to the maintainer, since Lua 5.3 is a bit of a mess). OpenResty, Cloudflare's Nginx+LuaJIT server engine (probably the largest use of LuaJIT in the wild, plus they also supported development of LuaJIT and the maintainers have contributed quite a bit of code to it) recently flipped the flag to "on" by default in their releases, so it seems like they're finally convinced as well.

[nomoon]

if luaJIT decides to go a different route, saying these won't be supported in the future, enabling them at any point will be more problematic than never having enabled it in the first place... imo.

These features were added between LuaJIT 2.0.0-beta6 (2011-02-11) and LuaJIT 2.0.0-beta11 (2012-10-16), and haven't changed since then. So I'm not sure stability is a concern. The LuaJIT 2.1 beta (which has been in progress since at least August 2015) also leaves them untouched.