Re: Strong tables in Lua 5.4

[Sean Conner <sean@...>]

It was thus said that the Great Roberto Ierusalimschy once stated:
> > Every `t[k] = f()` of every module and dependency (and their
> > dependencies recursively) would have to be checked for memory leaks.
> > And this won't be the typical Lua 5.x to Lua 5.(x+1) situation where
> > you try out a dependency on a new Lua version and it doesn't) build
> > because lua_dump now has an extra argument, or lua_objlen was renamed
> > to lua_rawlen in a Lua/C module, or you get a crash with a stack trace
> > in your testsuite because setfenv() doesn't exist anymore.
> 
> I still think you are exaggerating the problem, but I may be wrong. I
> would like to know how many real programs have the construction
> t[k] = f() where f() returning 'nil' is not a bug. (You mentioned
> that table.move could create that kind of thing. I asked for a real
> scenario, but got no answer.)
> 
> More concretely, I propose a little experiment: suppose that Lua raises
> a run-time error for every assignment of nils to tables except in
> explicit assignments with a constant nil (t[k]=nil). How frequently this
> error will occurr without hinting a hidden bug in the code? (Please,
> any answer should be about some piece of real, useful code where that
> could happen.)

  Less than a minute in, and I found a place what would break code I've
written (for work no less!).

  I have the following function:

	-- Okay, we store a coutine and arguments into a table for later
	-- running the it.

	function schedule(co,...)
	  RQUEUE[#RQUEUE + 1] = { co, ... }
	end

then later down in the code I have the following:

	-- We've timed out on waiting for something.  signal the error by
	-- returning nil and and error of TIMEDOUT

	schedule(obj.co,nil,errno.ETIMEDOUT)

  -spc