It may be helpful to remember in the context of the code aesthetics that Lua enforces almost no restrictions on where statements go. For instance, it is perfectly legal to write this:
do local i = 0 while i < 10 do i = i + 1
print("Not a for loop!")
-- loop body statements
end end
if you really want something that "looks like a for loop" with the desired behavior. Of course, the "end end" is a bit ugly.
And for an effective "emulation" of what a counted loop really does this should be instead:
do local i = 0 while i < 10 do
print("Not a for loop!")
-- loop body statements
i = i + 1 end end
(with the difference that the effective loop counter is a normal accessible variable. And I don't see what this the interest of a Lua adding a hidden variable (possibly in a register) when this is purely an implementation detail for its own local optimization. Even in C/C++ such detail, like inferring some derived register is performed by the compiler but does not break the contract that the loop counter is a normal variable, which may still be modified (the compiler detects such thing and will know that the inferred derived register is no longer an interesting optimization if it requires resynchronizing the hidden variable (such as using the (E)CX register on x86/x64 for using a "REP" statement or implementing and using a faster intrinsic implementation for memory moves/compares (this requires a specific register allocation as an optimizer hint, where the (E)CX register is no longer considered a generic register, and this is no longer a bug problem when you have now many more generic registers in x64; the compiler can infer the necessary sync'ing code using another register for the normal modifiable variable; memory copies are so common in all apps that it pays being able to accelerate, but it should not prevent using another register for modifiable loop counters without using explicit pseudo-optimizations just for counter loops in Lua).
So IMHO, Lua should have not put that restriction in its specification and really should have said that using a do loop like above, or a counted loops was strictly equivalent (and so that there was no "hidden" variable at all, adding more complications to the compiler and optimizer than any simplifications). The "counted for loop" should just be a "syntaxic suger", not even really necessary for the core language and not making any semantic difference and offering no runtime performance optimization, but just a "shortcut" for clarifying the source code in some common use cases. I do not like atall the concept of hidden variables that break the common semantics and force programmers to use less clear code.
In other words; just ban the existing "counted for" loops in your Lua code, it just adds potential bugs, and you don't need it at all. A Lua compiler should even warn you against using that trick (even if your code does not attempt to modify explicitly loop counter variable). The existing "counted for loop" is just dangerous, its semantics is ill-defined.
