Re: [proposal] Using nil/NaN as table index

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

2014-04-08 22:16 GMT+02:00 Peter Melnichenko <petjamelnik@yandex.ru>:
> 2014-04-08 22:41 GMT+03:00 Dirk Laurie <dirk.laurie@gmail.com>:
>> [...]
>> When setting a field, these two keys that are a priori known to be
>> non-retrievable helpfully throw an error instead of bequeathing
>> a thorny debugging problem to the user.
>>
>> That's a service, not an inconsistency.
>
> What's inconsistent, in my opinion, is that an error is not thrown
> when _getting_ a field using those non-retrievable keys, which
> may result in thorny debugging problems as well.

There are legitimate uses for those keys when one has a table whose
values will be used as keys. For example, the distinction between nil
(valid neither as key nor as value) and NaN (valid as value but not as
key) can exploited. I can distinguish between invalid index 3 (nil because
index 3 was never present) and invalid index 2 (NaN because some test
on element 2 was failed) in the following example:

x = {1,0/0,nil,2}
y = {1,2,3,4}
for k=1,4 do local z=y[x[k]]; if z then print(z) end end  --> 1 2