Re: Attributes

On 2026-05-24 19:34, Pier 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 
> <https://groups.google.com/d/msgid/lua-l/a7fc6ef3-698e-4857-8603-66a3474f1f0bn%40googlegroups.com?utm_medium=email&utm_source=footer>.

In the language plane Lua 5.4 added optional "attribute" element to
variable declaration:

   stat ::= local attnamelist [‘=’ explist]
   attnamelist ::= Name attrib {‘,’ Name attrib}
   attrib ::= [‘<’ Name ‘>’]

Lua 5.5 allowed attribute to precede variable name:

   attnamelist ::= [attrib] Name [attrib] {‘,’ Name [attrib]}

What "Name" here is implementation details.

Since 5.4 implementation-supported attributes are "const" and "close".

How good is support for "const" attribute is again implementation detail.

 From my usage experience of "<const>" in my code:

   * "<const>" is always in "local <const>"

     More clutter but code is actually more verifiable:

     If you see "local <const>" it means that we're just captured
     value under convenient name. There would be no hanky-panky with
     that value in code.

     Cases when we have just "local" are rare as is signal to
     divert attention to code.

   * "<const>" breaks Lua 5.3 which is mainstream "pure Lua" for me

     If you're using Lua 5.3 library your new 5.5 code will break
     there. So I just reverted my development from v5.5 to v5.3.


 > The SNAKE_CASE convention to me is more than enough to denote constants.

CAPPED_SNAKE_CASE is ugly abomination of ancient times! Well, it still makes
sense if you're working with paper listings from text printer in 2026.

 > I don't see any reason to include it, because
 > [...]
 > it doesn't make tables immutable!

"<const>" is declaration-time attribute. Making tables immutable since
declaration is a big overshoot. Proposed "table.freeze()" suits a lot 
better.

-- Martin

-- 
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/c5989611-728a-46ac-a598-457deffc2782%40disroot.org.