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

[Jeremy Ong <jeremycong@...>]

> 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.

Sometimes, the inconsistent definition is the useful one. 0! in math
for example is equal to 1 (ignore the riemann zeta function for the
sake of discussion). Matrix multiplication is performed with
row-column inner products.

In this case, you are talking about a fundamental change that would
certainly break many codebases for not much gain in my opinion.

On Tue, Apr 8, 2014 at 2:01 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 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
>