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

[Sean Conner <sean@...>]

It was thus said that the Great Egor Skriptunoff once stated:
> 
> *Remark #2*At second sight, this "undef" idea has big problems with
> compatibility.
> If I understood correctly, in Lua with NILINTABLES table keys
> with nil values will NOT be GC-ed.
> To release a key in a table, undef must be pseudo-assigned instead of nil.
> Unfortunately, this breaks most of old Lua code.
> Almost all Lua projects will need to change its internal logic
> to avoid memory leakage. (Memory leakage here is about having a lot of
> unneeded keys with nil values which are not available for GC)
> Yes, searching for literal nil assignment will find most of places
> we should change.
> But there would be a lot of hard-to-find places such as
>    -- func may return nil sometimes
>    t[k] = func(k)
> or
>    -- intentionally skips nils and stores only non-nils
>    table.insert(t, get_next_val())
> Rewriting old projects would be hard and error-prone.
> We all have a lot of old code we don't remember in details how it works.
> The price of rewriting Lua 5.3 code to Lua 5.4 will be too high.

  Hmm ... how about this?  Make undef a special value that acts like a
storable nil?  

	x = { 1 , 2 , nil , 4 , 5 }

x is *NOT* a sequence---nil is still nil.  But

	y = { 1 , 2 , undef , 4 , 5 }

y *IS* a sequence.  It's just that y[3] has an undefined value.  It can be
treated as nil, such that

	y[3] == nil -- this is true

This should avoid the problem with older Lua code that expects 

	foo.bar = nil

to have the key bar GCed.  Also:

	function foo(...)
	  local x = table.pack(...)
	  dump("x",x)
	end

	foo(1,2,nil,4,5)
	x =
	{
	  [1] = 1,
	  [2] = 2,
	  [3] = undef,
	  [4] = 4,
	  [5] = 5
	}

  You get rid of the x.n hack as well.

  -spc