Here’s something I don’t understand.
Why do we need the ugly, weird-looking and controversial <toclose> notation at all? (Also, “toclose” isn’t quite the right word anyway, but that is another matter.)
Yeah, well, I also wanted to nearly ask myself as well, but then did not want to start a flamewar.
From my point of view I would prefer “local” without the controversial <> notation as well:
local const foo = 123
I understand that change would render existing code incompatible which already used “const” for their own variables (well, seriously?, … their bad ;-)
I also understand the controversial and wired-looking <> notation is more flexible for the future. But do we really need that (keeping Lua small and such)?
Well, one could probably roll their own syntactic sugar to translate “ const “ to “ <const> “ though.
Btw. I have not looked at the implementation details, but it would be cool if a global:
local const debug = false
could be used by the compiler to optimize all the debug conditionals away in the bytecode, … at least that would be one useful use case for myself.
Thanks,
René
We don’t annotate variable declarations with <tofinalize> when they have a finalizer - we just set a __gc metamethod and that tells Lua it’s a <tofinalize> variable automatically.
A <toclose> variable *must have* a __close metamethod or else an error is raised when it goes out of scope. So why can’t the presence of a __close metamethod be the signal to Lua that it is handling a to-be-closed variable?
The <toclose> flag for a variable should simply be set automatically at runtime when the setmetatable() function is called for the variable.
PS. The __close metamethod is not documented in the Metatables and Metamethods section (2.4) of the manual. It should be. (The __gc metamethod is mentioned there but as a bit of an afterthought. Both of those special metamethods ought to be included in the formal list of events that activate metamethods, for completeness and clarity.)