|
On 2018-01-30 10:59 PM, Tim Hill wrote:
On Jan 30, 2018, at 6:55 AM, Soni They/Them L. <fakedme@gmail.com> wrote: Lua 5.3.4 Copyright (C) 1994-2017 Lua.org, PUC-Riometa = {__add=function(x, y) return setmetatable({i=x.i + y.i}, meta) end, __lt=function(x, y) return x.i < y.i end} function one() return setmetatable({i=1}, meta) end function two() return setmetatable({i=2}, meta) end function ten() return setmetatable({i=10}, meta) end for i=one(), two(), ten() do print(i) endstdin:1: 'for' limit must be a number stack traceback: stdin:1: in main chunk [C]: in ?local i,j,k=one(), ten(), two() while i < j do print(i) i = i + k endtable: 0x558de8c74080 table: 0x558de8c74200 table: 0x558de8c747b0 table: 0x558de8c74890 table: 0x558de8c74970local i,j,k=one(), ten(), two() while i < j do print(i.i) i = i + k end1 3 5 7 9 Rationals don't work. Only floats and ints do. This sucks.You are basically arguing that the numeric-for should switch from using raw types to instead check for metamethods (basically __add/__sub and __lt/__le). While I agree that, from a purist standpoint, you are right, I think you will find that the argument against this is performance related. The extra checks would degrade numeric-for performance when it was used for the far more common numeric type.
It would not. Integer and float are treated separately in the VM, but exposed as a single type.
They're physically distinct TValues.The VM already checks if ttisinteger. Floats and ints have the same performance. My proposal would make floats slightly slower (one extra check), but it'd also fix a major issue with the current implementation (an integral part of a lot of exploits out there), while not affecting int performance at all.
And of course you can always use the generic-for anyway, so why do you need this? —Tim
-- Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.