Re: Numbers in Lua 5.3work

[Tim Hill <drtimhill@...>]

On Jun 24, 2014, at 3:18 PM, Mike Nelson <mikestar1313@gmail.com> wrote:

> All the discussion about integers really has me wondering how this is all going to work. I feel that there is the potential for a lot of nasty surprises at the new behaviour of integers and floats silently interconverting. I can see how a distinct integer type would work: think C.  The integer subtype leaves me feeling uneasy. This is not a problem for my current use cases: I can stick with Lua 5.2 and its all number are floats (actually doubles in the default configuration) model, the same number model that has been used from the beginning. For use cases where I would need to work in integer but could dispense with floats, I can compile 5.2 with int or long as the number type.  Where 5.3 would be useful is when I would need actual integers but couldn't dispense with floats--but in that case, explicit integer and float types would work as well as  subtypes, with fewer surprises. Yet a full integer/float type system would break too much existing code. I don't envy the Lua team here--it's very debatable which is the best way to go.
> 
> Other features of 5.3work are quite good: The utf8 library is so good that I have backported it to Lua 5.2; and while my current use cases are not helped by moving bit operations into the core, it causes me no problems and is quite useful for those who use bit operations frequently.
> 
> -- Mike Nelson
> 

Even distinct types has problems. Consider tables, would t[2] and t[2.0] access the same entry? If not, lots of existing Lua code is going to break. Also see the thread regarding rounding floats to integers when (e.g.) indexing a string.

I think a lot of the problem is that the current docs don’t clearly differentiate integers from integral values. The string indexing thread, imho, is really about how to handle non-integral index values rather than integer vs float arguments.

—Tim