Re: Extending Lua for multiple light userdata types

[Javier Guerra Giraldez <javier@...>]

On Wed, Nov 14, 2012 at 10:30 AM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
> The point is exactly the "float with integer values are converted to
> integers" rule. It only holds for table keys. If I do
>
> t = {[1.0] = 1.0}
> a, b = next(t)
>
> Then b will be 1.0, but a will be 1 (an integer).

so, which would it be?  1.0 as in your previous email, or 1 as here?
(i'm ok with both, but feel 1 is more natural)


>> And if Lua gets an integer subtype, it would be natural to return
>> array indexes as integers.
>
> Remember that Lua has no such thing as "array indexes", only table keys.
> If you have a set of real numbers, some of those numbers may be subtly
> transformed into integers. (More often than not this transformation will
> be irrelevant ;)

well, i faintly remember that the array part of a table doesn't store
keys, so it's indexes for that part of the code.  If next(t) is
currently at the array part, it returns the (integer) index as a
(LuaNumber) key.  that's ok since the only number in Lua is a float.
But if we get integers, would it still convert back to floats? it
doesn't feel necessary anymore.

yes, it's slightly weird that
{[0.9]='a', [1.0]='b', [1.1]='c'}
becomes
{[0.9]='a', [1]='b', [1.1]='c'}

but that's how it works today.  an integer subtype would just make
this behaviour slightly more visible.

-- 
Javier