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

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

2014-04-08 18:57 GMT+02:00 Peter Melnichenko <petjamelnik@yandex.ru>:

> I think it is inconsistent that an attempt to use nil or NaN as a key
> when setting a field is an error:

Raw table indexing is just an efficient way of implementing direct search.
I.e. rawget(tbl,key) is equivalent to:

function lookup(tbl,key)
   for k,v in pairs(tbl) do
      if key==k then return v end
   end
end

So any value that cannot satisfy key==k is useless. That is why NaN
can't be a valid key.

How does pairs(tbl) know when to stop? Answer: k==nil is the sentinel.
By the time key==k is reached, k is known not to be nil.

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.