Re: [Proposal] -DLUA_NOCONVF2I and -DLUA_NOCONVI2F

[Michael Nelson <mikestar1313@...>]

On 7/19/2016 12:39 PM, Soni L. wrote:
> Float to integer conversions, especially the ones involving table 
> keys, are considered harmful by a lot of the people who replied to my 
> __key feature request. So instead I'd like to request -DLUA_NOCONVF2I. 
> It should make those people happier, as it removes the closest analog 
> to __key we currently have in the VM.
>
> -DLUA_NOCONVF2I would apply to anything that requests an integer, all 
> bitwise operators, and indexing operations. It should lead to a faster 
> Lua VM and more robust code, as well as a lot more runtime errors.
<snip>
I am not endorsing this proposal, but I'm offering what I believe to be 
a clarification of its intent in the long term (Soni L. can correct or 
amplify as needed).

The decisions made in introducing integers into Lua in version 5.3 need 
to be reconsidered. Integers should be a fully distinct type and should 
not interoperate with floats. Mixed mode arithmetic would raise an error 
absent metamethod providing for it. Conversion functions would be 
available as now, perhaps with additional functions added, and/or some 
current functions  renamed  In the case of equality checking as well as 
table indexing the value of 1=1.0 would be false. The type function 
would be modified so type(1) would return "integer". The type function 
call could be modified so that type(1.0) returns "float", although the 
return value could be left as "number" if the reduction in the amount of 
broken code is judged sufficient to justify the reduction in clarity. I 
would prefer the former (given the forgoing changes were made), as a 
great deal of old code will be broken in any case, and having the types 
"integer" and "float" seems more clear than  "integer" and "number".