Re: Proposal for table length operator

[Mark Hamburg <mark@...>]

So, why does this whole nil/holes/etc thing matter? Because it ends up being a subtlety that makes code work until you happen to use nil somewhere it wasn't expected. For example:

* Tables implementing stacks. An implementation that doesn't explicitly store a stack pointer works fine until one tries to put nil in the stack.

* __index table chaining to shadow values (e.g., inheritance chains) works until you want to shadow a value with nil. Then you need an __index metamethod and appropriate logic to control when to go looking up the chain even when the value is nil.

* Function result caching using __index metamethods works well until you try to cache a function that can return nil. Then you need a more complicated implementation that tracks nils and translates appropriately.

The problem is that nil is both a value that can be useful in computations and the representation of non-presence in a table. Mostly that's okay. When it isn't, code can break in surprising ways if one hasn't thought ahead.

Mark

P.S. Of course, for function caching, nil and NaN are also potential sources of surprise on the key side as well...