Re: Feature request: allow nil as table key

[Peter Cawley <lua@...>]

How would this interact with pairs/next? The current behaviour on
generic for loop iterators is to use nil to indicate both the start of
iteration (nil as the initial key) and end of table (nil to break the
for). If nil becomes a valid key, then both of these things need to be
addressed in order for the [nil]=value pair of a table to be iterated
over.

On Wed, Jun 10, 2009 at 6:16 PM, Jerome Vuarand<jerome.vuarand@gmail.com> wrote:
> Hi,
>
> Following some recent comments about the next version of Lua, I
> remembered a proposal I did on IRC (as doub) but forgot to post here.
>
> It would be nice to allow nil as a key in Lua tables. I don't see any
> syntactic or semantical reason to prevent it, and I'm sure any
> technical reason in the Lua sources can be overcome. It would have the
> same semantics as all other immutable values. The initial/default
> value of the nil key would be nil. It would then be read with "t[nil]"
> and changed with "t[nil] = value". It would be usable in a table
> constructor as "t = {[nil] = value}". Indexing with nil would trigger
> the __index and __newindex metamethods.
>
> The current behaviour could be emulated with a __newindex metamethod
> that raise an error when passed a nil second parameter.
>
> I think that modification would improve the overall consistency of
> Lua. It would save us from handling the current special case when the
> current behaviour is not needed.
>
> Please comment (and I'd love to have the authors opinion on the
> subject). I've never modified the Lua sources this extensively, but I
> could give it a try if a patch would help the feature being
> incorporated in the next version.
>