Re: Numeric key collision related bug in Lua 5.3

[Andrew Starks <andrew.starks@...>]

On Tue, Apr 21, 2015 at 4:00 PM, Coda Highland <chighland@gmail.com> wrote:
> On Tue, Apr 21, 2015 at 1:55 PM, Andrew Starks <andrew.starks@trms.com> wrote:
>> On Tue, Apr 21, 2015 at 3:46 PM, Coda Highland <chighland@gmail.com> wrote:
>>> nkey = (1<<63)-333
>>> fkey = nkey + 0.0
>>> print(fkey == nkey)             -> true
>>>
>>> t = {}
>>> t[nkey] = "nkey"
>>> t[fkey] = "fkey"
>>> print(t[nkey], t[fkey]) -> "fkey" "fkey"                -- Expected
>>> based on equality check above
>>>
>>> t[0] = 0
>>> print(t[nkey], t[fkey]) -> "fkey" nil           -- Unexpected
>>
>> Thank you for your patience. What am I doing wrong here? I only get
>> expected behavior:
>>
>>> nkey = (1<<63) - 333
>>> fkey = nkey + 0.0
>>> print(fkey == nkey)
>> true
>>> t = {[nkey] = 'nkey', [fkey] = 'fkey'}
>>> print(t[nkey], t[fkey])
>> nkey    fkey
>>> t[0] = 0
>>> print(t[nkey], t[fkey])
>> nkey    fkey
>>> t[nkey] = 'nkey'
>>> t[fkey] = 'fkey'
>>> print(t[nkey], t[fkey])
>> nkey    fkey
>>> t[0] = 0
>>> print(t[nkey], t[fkey])
>> nkey    fkey
>>
>> Andrew
>>
>
> You're getting different behavior because this misbehavior is
> sensitive to the specific construction of the table. What you've
> demonstrated here is that using the table constructor can result in a
> different internal representation than using serial assignment -- a
> fact that is already well-known, from many discussions regarding the
> behavior of "array part" versus "hash part".
>
> If you had reinitialized t to {} before the t[nkey] = 'nkey' line, you
> would be more likely to see the behavior under discussion.
>
> It may make a difference, too, if you used t = { [fkey] = 'fkey',
> [nkey] = 'nkey' } as opposed to the ordering you have now.
>
> /s/ Adam
>

Awesome. Thank you. FWIW, I agree that this is at least "unsettling."
Further proof that no feature is ever easy to implement.

-Andrew