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

[Tim Hill <drtimhill@...>]

> On Mar 13, 2018, at 12:43 PM, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
> 
> 
> Once you have nils in tables, t[i]=nil does not remove elements from
> a table anymore. For that, you need to write t[i]=undef.
> 
> No, this is not like JavaScript! 'undef' is NOT a value.
> 
> t[i]=undef is a special syntax form that means "remove the key 'i'
> from table 't'". You can only use 'undef' in three specific forms:
> 
>  t[i] = undef     -- remove a key from a table
>  t[i] == undef    -- test whether a table has a key
>  t[i] ~= undef    -- test whether a table has a key
> 
> Any other use of 'undef' gives a syntax error.
> 
> You still can create tables with holes, but you must get out of your
> way to do it.
> 
> The nice thing about this syntax is that it is compatible with
> previous versions of Lua (as long as you do not use 'undef' for
> other stuff). In Lua 5.0/1/2/3, if you write 't[i] = undef', you remove
> the element from the table. Even if we never change Lua to this
> new mode, even if you never use Lua 5.4, we think this syntax is
> a nice way to document whether an assignment is being done to remove
> an element from a table.
> 
> (A search for the pattern '][ =~]*nil' finds most of the places
> in your code where you could/should use undef instead of nil.)
> 
> -- Roberto
> 

Putting aside that this is experimental in 5.4 for the moment…

— What is the intended behavior of the “#” operator? From your examples it looks like it respects nils as “real” values.
— If this is true, what happens to the definition of a sequence?
— What happens to the definition of ipairs() ?

While I admire the cunning use of undef and the way it is backward compatible, I can see lots of old code breaking as tables fill up with nil values and consume memory (and this is nasty as such breaks will only happen when the code is stressed in low memory situations). It’s also a shame to break the symmetry and clean design of “nil means delete”.

—Tim