The interpreter also got many performance improvements under the hood.

>- utf8 library accepts codepoints up to 2^31

Interesting. Didn't Unicode restrict UTF-8 to allow encoding only 21 bits? Does it mean that it can now do 6 byte UTF-8 encodings? What kind of restrictions did it have before?

Comparing the documentation seems to verify this easily:

- https://www.lua.org/manual/5.3/manual.html#6.5

- https://www.lua.org/work/doc/manual.html#6.5

I don't see how this is a good change, it's like, back to 1994 utf-8

> coersions string-to-number moved to the string library

Does this mean + can finally be used for string concatenation and .. disabled as an opt-in C flag?

What would you use coroutine.close () for?

I suppose, just to close to-be-closed variables declared inside a sleeping coroutine.

Why not let the function in the coroutine exit normally?

Maybe I should go read the docs. Killing a coroutine from the outside looks like poor design/bad idea.

Lua 5.4 has a new feature called to-be-closed variables. It is intended to allow for deterministic freeing of resources, even in the face of possible runtime exceptions. (Sort of like RAII in C++).

The canonical example is that you can mark a variable holding a file handle as to-be-closed and then as soon as you exit the variable's scope the file gets automatically closed (including if exit early due to break, return, or error).

But what is supposed to happen if you are inside a coroutine and pause the execution before reaching the end of the scope, and never resume again? If there are any to-be-closed variables their destructors will never run! Or they might only run after the containing coroutine gets garbage collected, which is not a timely solution. To cover this situation, Lua 5.4 introduced a new coroutine.close function that kills a paused coroutine and runs the destructors of any to-be-closed variables inside it, if there were any.

Closing a looping coroutine from outside the loop?