Re: [ANN] Lua 5.4.0 (work1) now available

[Viacheslav Usov <via.usov@...>]

On Thu, Mar 15, 2018 at 7:41 PM, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:

> To make it clear: We are NOT TURNING THIS NEW SEMANTICS AS THE DEFAULT in Lua 5.4. (It is not the default even in this work version!!) LUA 5.4 WILL BEHAVE EXACTLY AS LUA 5.3 REGARDING ASSIGNMENT OF NILS TO TABLES.

For the record, I did not think 5.4 would change the treatment of nils in tables by default, but I admit that I used "5.4" loosely enough to stand corrected.

That said, I do not think that matters much. The "new way" can be made mandatory in 5.5, 5,6, 5.N or X.Y, the problems I mentioned won't go away. You obviously think that by making the change gradual you will make the transition easier, but I think most people will just ignore that until they have no other choice. The issue is not technical, and has a lot to do with the average Lua user - who is not a subscriber to this list and has no idea that he is supposed to be adapting his perfectly working code to some future Lua version.

In my opinion, table.foo = nil meaning "remove foo" is fine in a lot of situations, and there is no reason to make all the code doing that incompatible with X.Y. I'd instead think of an explicit opt-in, when a particular table is enabled to hold nil values, and a function like table.discard(tab, key) to remove keys from such tables. The opt-in could be some special table constructor syntax, especially if the nil-value behaviour should be chosen once and remain unchanged afterwards, or another table.* function that can change it during a table's lifetime.

Cheers,

V.