• Announcement: Lua.org now officially recommends this forum as a meeting place for the Lua community
  • The forum is currently open to new registrations. The registration will close for a short period of time when reaching 500 active members, to upgrade the server resources.

Thoughts on upcoming changes in 5.4? (1 Viewer)

mid

Newcomer
Joined
Jan 8, 2020
Messages
4
Reaction score
4
Location
Anonymous HQ.
Obviously, nothing is concrete as of the moment. I mean the potential changes that are still in discussion. So far, these were the (big only) changes:
  • Warning system. This is, AFAIK, a pretty controversial addition on the mailing list. I don't remember what the arguments against it are, but I remember agreeing. I'll look up the arguments soon.
  • %p specifier in string.format. Potential security breach, maybe?
  • To-be-closed or const locals. This, for me, seems like a needlessly complicating feature to add to a language. I would probably be more in favor if the syntax was a bit less ugly, although <const> can be done with just good coding practices. Any reason we can't just ditch close functions and/or let that happen in __gc?
  • Userdata now have multiple user values. AWESOME! Wonderful feature to add for all the backend developers.
  • I think the biggest (potential!) change is the addition of undef. This is, in essence, a fix to table holes that break the # operator and several other things. This feature is not enabled by default, as far as I'm aware, it's enabled via a macro and allows you to do something of this sort:
    Code:
    local t = {a = 1, b = 2};
    t.b = undef;
    And now, the table has length one. Right now, nil does this exact same task, it erases the key completely from the table. Whereas with undef enabled, nil instead would be placed as a value of the key, instead of erasing it. A more detailed explanation can be found on this e-mail by Ierusalimschy.
In general, my thoughts are "meh" . Perhaps I've said some out-of-date information, correct me if I have. I'll probably stick with 5.2 for a while.
 

younyokel

Member
Rank: I
Joined
Jan 8, 2020
Messages
15
Reaction score
18
Age
18
Location
Kazakhstan
Website
stackoverflow.com
I'd like to try Lua 5.4 but LÖVE which is a game framework I use, sadly handles only the 5.2 version.
 

stetre

Member
Rank: II
Joined
Jan 8, 2020
Messages
35
Reaction score
22
Location
Italy
Website
github.com
Is there any document anywhere that explains these changes and their rationale all in one place?

BTW, I haven't used the new features but I've been using 5.4 beta for a while now on my PC, and I barely noticed any difference with 5.3 (which is good news).
 

mid

Newcomer
Joined
Jan 8, 2020
Messages
4
Reaction score
4
Location
Anonymous HQ.
Is there any document anywhere that explains these changes and their rationale all in one place?

Not that I know of, unfortunately. Your best bet is probably the mailing list, which has the information scattered all around the place.
 

The_GTA

Newcomer
Joined
Feb 22, 2020
Messages
3
Reaction score
2
Age
28
Location
meowland
We cannot let everything happen in the garbage collector because you need files closed on-time and not sometime in the future if you want to handle OS resources reliably.

As for opinion on Lua updates on general, security features have been deprecated since Lua 5.2 removed the bytecode verification component. But ok.
 

dinsdale247

Moderator
Staff member
Community Patron
Creator of WinLua
Joined
Nov 17, 2020
Messages
69
Reaction score
27
Location
Victoria BC
Website
winlua.net
I had tried what is now the undef some time back when it was a compile option for NIL_IN_TABLES. I thought it was great because it gave safety when assigning values or manipulating data. I haven't looked into the latest proposal, but this seems to be the reverse of the last implementation.
 

Apickx

Newcomer
Joined
Dec 14, 2020
Messages
1
Reaction score
0
I don't like the new canonical way to override a table's __tostring mixed with print() no longer calling tostring() on it's arguments. Detouring is usual in Lua and I would have preferred it to be the way to override what an object's string looks like; I'm also worried about the expansion of responsibilities of the metatable.
 
Top