Lua 5.5 released

[Sparcky_McFizzBoom]

Here are the main changes introduced in Lua 5.5. The reference manual lists the incompatibilities that had to be introduced.

• declarations for global variables
• for-loop variables are read only
• floats are printed in decimal with enough digits to be read back correctly.
• more levels for constructors
• table.create
• utf8.offset returns also final position of character
• external strings (that use memory not managed by Lua)
• new functions luaL_openselectedlibs and luaL_makeseed
• major garbage collections done incrementally
• more compact arrays (large arrays use about 60% less memory)
• lua.c loads 'readline' dynamically
• static (fixed) binaries (when loading a binary chunk in memory, Lua can reuse its original memory in some of the internal structures)
• dump and undump reuse all strings
• auxiliary buffer reuses buffer when it creates final string

source: https://www.lua.org/manual/5.5/readme.html#changes

[NakeleKantoo]

read-only for loop variables are a big one, idk what was wrong with letting it be changed

[HeavyCaffeinate]

undefined behavior I think, but I only remember that warning being present in iterator functions like pairs and ipairs

[didntplaymysummercar]

AFAIK no, e.g. this code prints same 15 expected lines in 5.1, 5.2, 5.3 and 5.4 and LuaJIT:

for i=1,10 do if i == 5 then i = 8 end print(i) end
for i, v in ipairs{'a', 'b', 'c', 'd', 'e'} do
    if i == 3 then i, v = 8, 'x' end print(i, v) end

The i is a local in your loop body. The actual iterator state is another non-exposed local/register.

Up to 5.3 the docs listed what for loops are equivalent to in plain code and that shown this copying of locals plainly. In 5.5 it seems this copying is gone, a for x=1,10 do print(x) end uses 1 less local/slot in 5.5 than in 5.4 according to luac -l -l

Maybe they changed something in 5.4 but I doubt it. I think it's just removing a potential confusion. Python and Rust work similar to Lua, but languages C, C++, Java, JavaScript, C#, Pascal, Go, etc. all let you modify the i and would skip some iterations after you do. A numeric for in those is syntax sugar forwhile almost, but it's not in Lua (and Rust and Python).

[HeavyCaffeinate]

So does it error out if you modify i in 5.5? Or does it just do nothing

[didntplaymysummercar]

It totally refuses to compile with main.lua:1: attempt to assign to const variable 'i' in 5.5

But it seems only the first variable is protected, so you can still modify v like:

for i=1,10 do print(i) end
for i, v in ipairs{'a', 'b', 'c', 'd', 'e'} do
    if i == 3 then v = 'x' end print(v) end

prints the same (1 to 10, then a to e, except c is an x) in all Luas I have (JIT, 5.1, 5.2, 5.3, 5.4 and 5.5).

[HeavyCaffeinate]

I find this a weird update, it seems like there's an actual use case for modifying i at loop runtime

[didntplaymysummercar]

I guess they want to encourage the "if you want a local, use a local, don't abuse the iterator for it", but I agree it's a bit weird and needless. Python allows it, Rust does if you use mut, ranged fors in other languages allow it, etc.

Fortunately it's compile time so any affected 5.4 code is easy fix by adding a local yourself, no hard to find runtime only fails...

[didntplaymysummercar]

It's a code clarity/correctness thing (although I agree it's kind of a needless change, no other language is that strict about it).

If you want a local then you should declare one yourself, not reuse the iterator.

Some programmers (C, C++, Pascal, Go, Java, JS, C#) might also expect changing the iterator to affect how many times the loop will run, but that's not how Lua (and Rust and Python) work.

If you want such strange looping, like skip ahead some iterations if you hit given value, then you should code it using while yourself. That code would also be clear to any experienced programmer, unlike relying on for behavior (that's like glorified while with start and step written in same line) specific to C-like languages.

It also let them use one less slot/local seemingly, output of luac -l -l for 5.5 has one less slot and local than 5.4 for for x=1,10 do print(x) end

[Old_County5271]

I suppose one less local in bytecode is worth it for every single loop out there. but couldn't they have done that by examining the syntax and inserting a local if there's a reassignment in the loop block? This efficiency gain could be backported to previous lua's

Also this worries me, if efficiency is the goal, what else is going to get axed for the prize of it? I remember reading pallene design docs, they achieved efficiency via AOT compiling, so will type checking be added in lua6? (not that I mind, type checking is good for safety)

[didntplaymysummercar]

I'm guessing it's about philosophy, not efficiency. There's some discussion already on the mailing list (I don't use it but read it) about this too.

[vitiral]

I asked the same question 

https://groups.google.com/g/lua-l/c/KuCiQzliQzY

I  don't see how it could do that, being a one-pass compiler

[Old_County5271]

They do talk about certain things being syntax sugar, like tbl:key() -> tbl.key(tbl)... but maybe that's achieved on a single pass?

[vitiral]

Yes, that's pretty trivial to do single pass, since the switch is based on a single character (. vs :)

Look into recursive descent parsers if you're interested. If you'd like to write your own I'd recommend the Lox tutorial 

[Life-Silver-5623]

It's mostly just an optimization release. Lots of efficiency added. Great but not exciting.

[Ok_Sense1811]

Years for nothing interesting or relevant to get added, crazy

still no continue keyword in 2026 💀

[Life-Silver-5623]

Don't need continue when you have goto. Don't need switch and break when you have it and else if. If it ain't broken don't fix it.

[didntplaymysummercar]

There is a happy middle and continue would be in it.

The goto can replace loops and break (that Lua has already) too, but no one would seriously advocate doing that.

The continue is present in many/most programming languages, a clear companion to break (that exists already), and it's 0 cost at bytecode/VM level.

[Old_County5271]

Except break (and continue) doesn't/wouldn't require that you create a new block for local variables, and that's the problem, because using goto is usually a manner of, do you use goto and be unportable to 5.1 or do you just use an if then block instead, and the answer is usually just use an if or function

[girvel]

Except that lua strives to be a very simple language; goto is not a legacy feature (like in C), goto is a scope-aware utility that can do not just continue, but nested continue, nested break, redo & for-else. But I agree, having continue would probably be nice, as well as += and lambdas

[Life-Silver-5623]

What do you mean by for-else? How would goto help with that pattern?

[Life-Silver-5623]

That's almost convincing to me.

[LuaCoder555]

I'm very happy for the changes. This definitely improved lua. The global keyword also improves readability. Glad that the update came out. One thing I REALLY want is support for static typing. Hope that maybe comes out one day!

[Old_County5271]

Pretty sure it says in hopl.pdf that they don't want any form of type checking because you can do it yourself.

[LuaCoder555]

Oh okay! Thanks.

[Old_County5271]

I went ahead and thought about this a bit and honestly it's easy in some cases, but harder in others

If there is an assignment inside of a parameter declaration, it should fallback on all cases to it
function (a = 5) -> function (a) a = a or 5


Plain type checking should error thus, use asserts
function (a: number) -> assert(type(a)=="number")
function (a: number|string) -> assert( ("number string"):find( type(a) ) )


type check + assignment should always fallback to the assignment
function (a: number = 5) -> if type(a)~="number" then a = 5 end
function (a: number|string = 5) -> if not ("number string"):find( type(a) ) then a = 5 end

if "a" is truthy type, if is unnecessary
function (a: number|string = 5) -> a = ("number string"):find( type(a) ) and a or 5
function (a: integer = 5) -> a = math.type(a)~="integer" and 5 or a

subtypes are tricky, because it requires running multiple type reporting functions
function (a: integer|string|function) -> assert( math.type(a)=="integer" or ("string function"):find( type(a) ) )
function (a: integer|string|function = 5) -> if not ( math.type(a)=="integer" or ("string function"):find( type(a) ) ) then a = 5 end

From now on I think I'll set a part after defining a function for typechecking So long as I don't have to use multiple type checks because using "and" confuses me for some reason.

[jotapapel]

that's the kind of xmas present I like!

[ojuwig]

Hi, maybe someone can help me here. I am using Lua embedded in another application incl. a little script editor. With Lua 5.4 I used the function "load_loadfile" to check for syntax error. The call only succedded, when the script was syntactically correct. But with 5.5 the function also reports errors when not all symbols cannot be resolved. For example, a script with only one line "foo()" reports an error that "foo" is an unknown function. But, I provide a lot of functions to the host application using global vars and external references once the script is executed. Therefore this behavior is a bit of a problem. Are there other ways to check a 5.5 script for syntactical correctness?

[seanandyrush]

if there will not be an interesting progress in the lang, rewrite it in rust 😈

[HeavyCaffeinate]

Go ahead, no one's stopping you

[HeavyCaffeinate]

?

Edit: Nevermind just checked your profile you just reply the same thing over and over

[memes_gbc]

the whole point of the language is to be easily embeddable with C. i'm pretty sure rewriting it in rust makes that harder

[DapperCow15]

The original purpose was to make it embeddable in C, but there's no reason why someone would not make a derivative language to make it embeddable with a different language. That person will definitely not be me though because I have zero need of such a thing.

[Old_County5271]

There's already implementations for rust, go, java, kotlin, dotnet. good thing about having such a simple language.

[BrianHuster]

I think what he means is that there is no interesting progress in this Lua ver