Re: Why is nil not a valid table key?

[Wim Couwenberg <w.couwenberg@...>]

> I know, it's always been that way. But is there really a compelling
> reason?

Well, "next" en iteration code should change.  Other than that, nil as
a key doesn't (theoretically) seem to be that much different from
other key values.  For example, the following is pretty clear:

-- make a function out of a table
-- and allow nil in the domain
function tablefun(table, nilvalue)
  return function(key)
    if key == nil then
       return nilvalue
    end
    return table[key]
  end
end

table = { ... }

-- make table into a function
fun = tablefun(table, "aap")


Now table[x] is the same as fun(x) except when x is nil.

> That's not technically correct, though: vec might have a nil element in
> the specified range, and then line 4 will blow up.

Wouldn't line 2 also be unreliable (because of the #vec being
undefined?)

> nil is certainly in the
> range of foo[x]; why should it not be in the domain?

If nil is in the range, then surely *all* values are in the domain?
;-)

If the domain (of a table) is defined as "the set of keys in the
table" then shouldn't the range be defined as "the set of values in
the table".  That would exclude nil from the range.

--
Wim