Re: Integers-related trap in Lua 5.3

[Daurnimator <quae@...>]

On 17 May 2016 at 12:57, Sean Conner <sean@conman.org> wrote:
> It was thus said that the Great Soni L. once stated:
>>
>>
>> On 16/05/16 07:09 PM, Sean Conner wrote:
>> >It was thus said that the Great Egor Skriptunoff once stated:
>> >>Hi!
>> >>
>> >>It appears that in Lua 5.3 usual call to tonumber() is not enough
>> >>to correctly parse numbers entered by user from file or keyboard.
>> >>For example,
>> >>local googol = tonumber("1"..("0"):rep(100))
>> >>gives zero (instead of 1e+100 as in previous Lua versions).
>
>> >  I've read the other messages in this thread, and my question is:  why
>> >was the behavior of tonumber() even changed for Lua 5.3?  Have it always
>> >return a double because math.tointeger() exists to parse integers.  You
>> >want a number, use tonumber().  You want to ensure you parse an integer,
>> >use math.tointeger().  That would at least prevent problems like this
>> >from happening in the first place.
>>
>> math.tointeger(9223372036854775807.0) ~= 9223372036854775807 so it can't
>> just always return a double. But it would be nice if it was smart about it.
>
>   You misunderstood me.
>
>         tonumber() always returns a double or nil if not a double
>         math.tointeger() always returns an integer or nil if not an integer
>
> tonumber() isn't smart.  math.tointeger() isn't smart.
>
>   -spc

tonumber() should always parse numbers the same way lua would.
If lua has literal integers, it should return integers
If lua has literal doubles, it should return doubles.

This keeps identities such as tonumber(tostring(mynumber)) == mynumber
as well as reducing surprises.

Yes there is a math.tointeger; perhaps you also want a math.tofloatingpoint()?