The biggest new feature appears to be local variable attributes. You can now annotate variables with `const` or `toclose`. The former prevents reassignment, and the latter runs a metamethod upon the local going out of scope. There's other new stuff in there like a generational GC, a runtime warning system, and the ability to store Lua values with a userdata, but I think these were in prior 5.4 work versions.
Ability to store multiple values (uservalues) with a userdata. Since Lua 5.2 one has always been able to store a single uservalue, which could be a table storing as many items as you wanted. Lua 5.1 had the concept of environments, which had the same role as uservalues for userdata types.
Being able to store multiple uservalues with a userdata type is quite convenient and cuts down on garbage objects (i.e. table container). Also mirrors the ability to set multiple upvalues for functions.
These are the kinds of features that really make Lua shine in terms of embedding and extension. Lua has rich interfaces for efficiently and conveniently associating native (e.g. C) objects with Lua objects and vice-versa. Other languages are rife with hacks as they only provide the simplest such mechanisms, if at all.
By contrast, the new warning API seems dubious. It's a great idea conceptually but logging is the sort of interface that generates a ton of friction in terms of composability and integration. It's impossible to please even a substantial minority of people. That said, I already have ideas for how to use it.
Can you share any of your potential used for warn()? I think I'm not really understanding it? Why is is better or different than print() or protected calls?
My latest project is a PC/SC and PKCS#11 driver framework. There are a few places in the C code, particularly the driver entry points before calling into Lua, where you can't bubble up an error context--you're limited to returning an error code to the caller--but for debugging and diagnostics you really want some context. Currently I just fprintf to stderr because it's not worth the hassle to call the logging code written for the Lua part of the drivers, but this new warning infrastructure provides a clear path for doing this--just replace the calls to fprintf with lua_warning (or a wrapper for vararg formatting).
It would be trivial to have done this myself, but it's one of those things you abstain from doing because you don't want the burden of making the choices (e.g. how to manage the global singleton hook), maintaining the code, and perpetually resisting the urge to refactor it.
My guess is that the warn global in the Lua environment was primarily added for symmetry with lua_warning. It's notable that there's no counterpart (AFAICT) to lua_setwarnf provided for Lua code. I think the warning API is principally a feature for C code.
I still think it's a dubious addition and will end up generating friction. It's the kind of thing people love to hate. For example, I bet it won't be long before someone complains you can only pass a single string rather than an object like with lua_error or multiple value like with lua_call/lua_yield. I won't complain about it, though. =)
EDIT: Reading the mailing-list and the code (grep for luaE_warning), it looks like this interface was principally added for the GC so __gc metamethod errors could be reported without throwing exceptions at random places in the code (i.e. where ever the application happened to be when the GC finalized an object).
Here's a more detailed list, for the curious:
- Changes since Lua 5.3: https://www.lua.org/work/doc/#changes
- Incompatibilities with the Previous Version: https://www.lua.org/work/doc/manual.html#8