> First, in a dynamic language, it is hard for me to imagine that something like this wouldn't effect the hot paths within Lua.
I understand that nothing is for free, but before we invoke the performance argument, it would be nice to measure the true effect on performance.
Besides, deterministic finalization could improve performance, because having a block-scope variable very likely means that it won't be used again, which the GC could use as a hint for some advanced optimization.
> Second, I wonder if this issue is limited exclusively to userdata, given that this is where big huge opaque objects that obfuscate their memory impact from the garbage collector. If so, then maybe that would change the approach to solving the problem.
I do not think I wrote anything that is specific to userdata. If there is something else, say a table, with a non-trivial finalizer to it, then the proposed approach would also take care of that.
> Conversely, if it is not, it seems like there would be no way to do this cleanly, without replacing the garbage collector, or simply running a bunch of times, which in some use cases would partially eliminate the purpose.
I do not think I understand why what I proposed cannot be done. This is done in a few garbage collected languages, so we are not inventing something new here.
> Finally, a comment: This appears to be something that would/should effect many people, but that not many people think it effects them (me). That is, I'm sure it does effect me and this thread has led me to study RAII, so thanks!
Your comment about being enlightened about RAII might explain why not many people [1] complain about that. Not knowing that an elegant solution to a problem exists may just keep people thinking that all they have is a bunch of inferior options. My background is C++, so RAII is my second nature and not having it hurts. Another reason this is important for me is because I am using Lua as a way to script activities in system, with potentially a large number of concurrently executing scripts, where those scripts could be written by end users who are not necessarily experts in Lua or any programming language for that matter, and I can safely predict that they will be leaking objects, both because of simply not calling their close() methods and because of errors that prevent the close() methods from being called. We can of course educate our users, but it is one thing to say "use block foo = bar()", and quite another to say "decompose your program functionally so that every acquisition of a resource that needs to be finalized is wrapped in a pcall and finalization is invoked regardless of errors".
Cheers,
V.
[1] With all the links to previous discussion/works on this issue, I would say this is a fairly well known issue.
