Re: Nil in table proposal

[Roberto Ierusalimschy <roberto@...>]

> It seems that to this purpose we need somehow to store nil in table as
> any other value. However, what really tables did with nil is a
> next-order problem, the main concern is how users interact with table
> content. For the simple access THERE IS NO DIFFERENCE between nil in
> table or not:
> 
> ```
> local t = {}
> t[a] = 1
> t[a] = nil
> assert(t[a] == nil)
> ```
> 
> Does it means that nil is in the table? Does it means that the the
> value is missing? Who cares? Chose the best semantic for your problem
> and go ahead.
> 
> But, there is actually a place where you can distinguish the two
> cases: table iteration (# is a form of table iteration). [...]

This is a nice rational study of the situation. However, there are at least
two other constructions where we can distinguish the two cases:

1) Garbage collection of the corresponding key. In your example, can
'a' be collected? (We can argue that this case follows from iteration:
if 'a' appears in an iteration, it must be kept; otherwise, it could be
removed.)

2) Metamethods: is 't[a]' "empty" for the point of view of calling
metamethods? An access to t[a] should call __index? An assignment
should call __newindex? (This is big difference and independent of
iterations.)

-- Roberto