Re: Attributes

Const does enable new optimizations (for example some constant folding, I believe). Write some toy programs and look at the bytecode. In a two(+) pass compiler (like LuaJIT) it'd make no difference as the compiler sees when variables aren't written to, but PUC Lua is one pass.

Personally I'm no big fan of the syntax. Compared to e.g. the JS const keyword, it's quite verbose for an attribute which, depending on programming style, the majority of variables receive. In the spirit of simplicity, I think it'd be reasonable if Lua just continued not to have const local variables, for similar reasons to yours.

A variable attribute should apply to the variable, not to a value stored inside of it. Const tables would be better implemented using a "table.freeze" method or similar. I also wouldn't confuse this with SNAKE_CASE, which is typically for "load-time", global constants specifically, not for all local constants.

- Lars

On 24 May 2026 19:34:22 CEST, Pier <[email protected]> wrote:
>I absolutely love Lua for how easy it is to learn, how clean the syntax is, 
>and how extendable it is. However, I do have a few thoughts on attributes 
>which was in introduced in Lua 5.4 that I think deserve a good discussion 
>maybe.
>
>The concept itself is not bad and the syntax is a fair compromise. The 
>close attribute is amazing when working with systems where freeing memory 
>is important but easily overlooked or forgotten (i.e. closing files). On 
>the other hand, the const attribute is just... meh. I don't see any reason 
>to include it, because as far as I know it doesn't add any performance and, 
>importantly, it doesn't make tables immutable! The SNAKE_CASE convention to 
>me is more than enough to denote constants. I hold onto the belief that 
>developers are component enough to not make stupid mistakes such as 
>changing variables that aren't supposed to be changed or changing variables 
>in an unexpected way. Even if that does happen, they are usually caught 
>through pull-request or during test. I don't know many teams that allow 
>anyone to change the codebase freely.
>
>I guess for const to be useful it would have to add some extra benefit than 
>just protection. I am no compiler designer, but if I had to come up with 
>something I would say constant tables could be immutable and optimized 
>internally since the keys would never change, or constant variables being 
>expanded. I'm sure there are many ways to go about it. 
>
>In the end, I still love Lua lol. Maybe I'm missing some context or 
>something, so I'm always happy to continue the discussion on this topic.
>
>-- 
>You received this message because you are subscribed to the Google Groups "lua-l" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
>To view this discussion visit https://groups.google.com/d/msgid/lua-l/a7fc6ef3-698e-4857-8603-66a3474f1f0bn%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups "lua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/lua-l/811E6654-B5E0-483E-9662-8E29F02A69A1%40gmx.de.