
Lua 5.4.0 (alpha-rc1) now available - AlexMax
http://lua-users.org/lists/lua-l/2019-05/msg00348.html
======
AlexMax
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.

Here's a more detailed list, for the curious:

\- Changes since Lua 5.3:
[https://www.lua.org/work/doc/#changes](https://www.lua.org/work/doc/#changes)

\- Incompatibilities with the Previous Version:
[https://www.lua.org/work/doc/manual.html#8](https://www.lua.org/work/doc/manual.html#8)

~~~
wahern
> ability to store Lua values with a userdata

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.

~~~
pull_my_finger
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?

~~~
wahern
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).

