May be you save 1 byte in source code, but at runtime it's horrible: you create a new table object to use the double value as a key (which is then converted to integer using an unspecified rounding mode...) initialized to a dummy value 0. Then you use the next iterator to extract that key, and the table will be garbage collected. This needlessly stresses the memory allocator and the GC. And it will be very slow compared to math.floor() or math.ceil().
I'm also not really sure that a table index is necessarily an integer and cannot be a double value.
The only restriction being that it should not be a NaN value, because it is not comparable. But any other double value can be potentially be used as valid index (including non-integers, infinites, and denormals which are comparable and ordered within the set of doubles minus NaNs). So this pseudo-"technic" is very likely to not be portable/supported.
The official doc currently says "Any value can be used as a key (not just numbers and strings) just make sure it's not nil or NaN (Not a Number)".
It means that a table like {[0]='A', [0.1]='B'} is valid and contains two distinct pairs because keys 0 and 0.1 are both valid and distinct.
You are probably using an implementation of Lua which adds the restriction to number keys for forcing them to be native integers (and then allow the backing store to be optimized by not requiring a storage vector for all integers keys, but only for numeric keys that are not part of a sequence) and otherwise store string lkeys separately.
So, next{[0.1]=2} should return 0.1 (the single key which is not nil and not NaN), and not 0 (some other rounded integer key)...
And your code "x=next{[x]=0}" MUST certainly fail with a runtime exception, if ever x is NaN or nil (invalid key): nothing will be stored in x, and the next iterator will not even be called, or an empty table may be silently created and the next iterator will return nil (no more keys in table) and then x will be assigned a nil value (which will be different "nil" type and no longer a "number" type).
