# Nil in table proposal

5 messages
Open this post in threaded view
|

## Nil in table proposal

Open this post in threaded view
|

## Re: Nil in table proposal

 > 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
Open this post in threaded view
|

## Re: Nil in table proposal

 On 21 March 2018 at 10:17, Roberto Ierusalimschy <[hidden email]> wrote: > 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.) Under pocomane's proposal, I would expect the behavior of metamethods to follow from the table mode: for normal tables, the 5.3 behavior; in keep-mode, a "stored" nil would be treated as an existing value, so t[a] set to nil wouldn't trigger metamethods on access or update. Another nice thing of this proposal is that for every existing Lua 5.x program there is a statically-computable upper-bound of additional memory that it would use if table constructors become nil-storing normal-mode tables by default (often with probably no memory increase at all on average, due to the delete-on-read/iterate semantics of normal-mode). The only downside is again the "JavaScript equality effect" [1]: `keep{...}` would become the "right way" to collect arguments and the obvious one would remain the "wrong way". Still an improvement over select/table.pack, perhaps? -- Hisham [1] new form is introduced to do something with better semantics (===), old one can't be removed/updated due to backwards compatibility (==).