My mistake for making it seem like I was primarily arguing that locals are better for performance and this should be the biggest reason for having an import(). The main reason *is* brevity. But if I say brevity I'm treated like I'm lazy, if I say efficiency I'm flooded with "well why not LuaJIT?", and no matter how many times I try to politely remind people I'm still reading suggestions involving _ENV. I get it: For most cases touching _ENV works, but I do not agree that is is convenient or appropriate ALL the time. I still get this overwhelming sense of "feature suggestion? BURN THE WITCH" from this list.
If your main reasons is brevity then I would agree some syntactic sugar does have some potential. I think, however, that you would still have to explicitly list every single item. That said, it would still make sense to do something like:
local from table.insert, table.delete, x, y.z.k
As sugar for:
local insert = table.insert
local delete = table.delete
local x = x
local k = y.z.k
This approach is pure sugar; as long as the list is explicit names then there is no conflict between compile-time and run-time knowledge, and you end up with cleaner code with almost no compiler overhead. The problems only arise if you try to impute the list from the run-time contents of tables.
As for burn the witch … One of the benefits of Lua is it’s adherence to “smaller is better”, which is good (imho). However, as with all such philosophies, there is always the danger of dogmatism. And yes, I think sometimes there is a little too much vociferous objection to suggestions here. This is a shame, as it tends to put off people making or supporting suggestions for new features, which in turn obscures which new features people actually do want. I admit I’ve pretty much given up on making suggestions here for that reason.
—Tim