Re: Deprecating setfenv()

[Mark Hamburg <mark@...>]

Now that I've spent a little more time looking at the Lua internals, I start to wonder why Lua doesn't store the environment in the CallInfo and just use the value attached to the closure as part of the CallInfo initialization. This was the semantics that the stack indexing for setfenv/getfenv had led me to expect though the manual said otherwise. It is also the semantics that would map cleanly to what "in env do end" is doing. It would also readily enable a call_with_environment construct which would override the environment in the closure on a temporary basis thereby handling Leo's use case.

If it just needs to work for Lua closures, then the space is already available in CallInfo. If it needs to work for C closures as well, then CallInfo will have to get bigger which is a bit of a performance hit. That, however, saves needing to look in two different places in getcurrenv. Other than the potential call info size issue and the need to initialize one more field on a function call, a scan of the code indicates that this shouldn't be a performance hit.

If it did work for C code as well, this would also make the C code for table.pack safe with respect to GC leaks. The current code leaves the last packed result hanging around in the environment for the pack function.

Mark