This has been a small debate in a couple of my Lua circles for a little while. I've never quite understood the thoughts behind this new feature. Today, I took some preliminary observations into the bytecode behind 'const' and non-constant counter-parts.
What I learned when doing this, is that constant locals which are associated with immutable values will behave more like a preprocessor macro than a position on the stack.
For example, printing a constant local defined as "my number" then printing it will produce the following bytecode:
0+ params, 2 slots, 1 upvalue, 0 locals, 2 constants, 0 functions
1 [1] VARARGPREP 0
2 [2] GETTABUP 0 0 0 ; _ENV "print"
3 [2] LOADK 1 1 ; "my number"
4 [2] CALL 0 2 1 ; 1 in 0 out
5 [2] RETURN 0 1 1 ; 0 out
Which is absent from the MOVE instruction from the non-const counter-part, so LOADK puts the value of the constant local directly into the instances of the local, instead of MOVE taking the value from the local.
Conversely, when a mutable value like a table is associated with a constant local, there are no bytecode differences, which means that a const local for a table is essentially identical to a non-const local, minus compile-time semantics like reassignment.
I know Lua is typically constrained on features because it wishes to preserve small binary sizes, but the const feature seems redundant with my current understanding. At this point, I don't know why it was added. Why was it added?
