Re: Extending Lua for multiple light userdata types

[Dirk Laurie <dirk.laurie@...>]

2012/11/14 Javier Guerra Giraldez <javier@guerrag.com>:

>
> currently next({[1.0]=true}) returns 1.0, but the key is internally
> just '1' (well, it's not a key, but an index on the array part), it's
> converted to integer when entering array code, and back to float when
> returned to Lua code.
>
> if the "float with integer values are converted to integers" is
> conserved, then i'd guess that {[1.0]=true} is exactly the same as
> {1]=true}.  And if Lua gets an integer subtype, it would be natural to
> return array indexes as integers.
>
> so, i'd expect next({1]=true}) returns 1 and next({[1.0]=true}) would
> have to be the same, unless it kept the original float key.

We're in for a lot of fun on this list.  At the moment the only pathological
case (reported as a bug every so often) is

>    a={}; a[-0]=false; a[0]=true; for k,v in pairs(a) do print(k,v) end;
-0	true
I.e. the original key but the new value.

If we have floats and 64-but integers possible at the same time,
analogy dictates that after

>    a={}; a[1.0]=false; a[1]=true

there will be a key-value pair (1.0,true).  If default print format stays
as it is now, you won't see the difference if you print it, though. Nice.
In the sense "calling for very fine discrimination", that is. :-)