Lua 5.3: 1 Month of use

[Andrew Starks <andrew.starks@...>]

These are some thoughts about 5.3, coming from a new project that
began using Lua 5.2.

##C API:

There were no issues. The only work was caused opportunity to use
64-bit integers. However, the native C-type  that we most often use is
unsigned, so we need to do some work to trap comparisons and to see if
there are any weird issues.

Whether or not float precision was a real issue, having integer divide
when dealing with nano time is addicting and I would not want to go
back.

##Module support:

There were minor tweaks required, mostly because modules checked for a
specific version. Some failed tests that counted on tostring returning
a value without a ".0", when integers were given...

##`tostring` and //

The switch of tostring returning "2.0" instead of "2" is somewhat significant:

> = 2
2
> = "2" + 0
2.0

If you're serializing Lua code that is to be read on the other end,
then it is trivial to make a pretty printer that will deserialize into
floating point keys, such as `t[1.0] = "foo"`. Mostly this just looks
funny as the speed of conversion is probably negligible.

There are a few other cases where you need just the integer of a
result and you want to append it to some other text, like when you're
formatting a number with commas, a social security number or a phone
number. There is a decent amount of implemented Lua that will return
"1.0,234.0,567.0" (1,234,567), "+1.0 (612.0) 555.0-5555.0" (+1 (612)
555-5555), etc.

The fix for this feels different than even the one for _ENV/setfenv.
You can overload or replace tostring to check for an integer and
return the integer portion but this is a "patch" that brings back old
behavior. If you want to use "//" but also need to support users of
older Lua, then you have to have access to "load", or require and
pall, or  a macro processor...

Also, code that uses "//" consistently will be different than code
that uses "math.floor", every now and again. Let's say that you want
an integer value to appear, without a ".0":
--5.2 behavior
> = string.format("%s", n)
1001
--5.3 behavior
> = string.format("%s", n)
1001.0
--you fix it like this, and most of the time it will work, especially
if you keep the number as an integer.
--here, it doesn't work
> = string.format("%s", n // 1)
1000
--it does the same thing as this, which has the same result in 5.2
> = string.format("%d", n)
1000
--this is the better fix
> = string.format("%.f", n)
1001

When I see ".0" in tostring or print("%s", my_num), it reminds me that
I'm seeing a float value that happens to be an integral. As a Lua
user, since I only have access to "numbers", I am getting this hint is
a rare view into what is almost an implementation detail. I can see
good reasons why "%f" as default was proposed over "%.f". However, I
can't say that I think it improves things.

There are many casual users that will run into subtle issues, because
of this. Floating point considerations were always with us. However,
they are going to be more *relevant*, now that there will be many more
times when people will need to lop off the '.0' and some of their
chosen methods will have unforeseen consequences. Adding the '.0' has
none of the potential rounding hazards, by contrast.

I will also add that if dropping number->string conversion is a
consideration, my suggestion is to do it at the same time as integer
divide / 64 bit int. My opinion is that it is better to do these
changes in one go and since you've already made the ".0" change,
people are more likely to be refactoring that code, anyway. If you
reverse and decide to go back to "30" and not "30.0" (from the prior
example), then I do not think that it is important to time coercion
deprecation with ints.

Finally, my concussion is that integers / integer divide is a very
welcomed feature that adds a great deal to Lua. It is somewhat more
disruptive than I expected.

Thank you for reading this! I hope that it was helpful.

-Andrew