Re: [proposal] Using nil/NaN as table index
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: [proposal] Using nil/NaN as table index
- From: Dirk Laurie <dirk.laurie@...>
- Date: Tue, 8 Apr 2014 21:41:26 +0200
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.