Re: Odd semantic with nil in tables

[Aki Tuomi <cmouse@...>]

> On 01/17/2023 1:17 PM EET Marcus Mason <m4gicks@gmail.com> wrote:
> 
> 
> > Yet, if we do
> >
> > > foo = {}
> > > foo[nil]
> > nil
> 
> > it works. Why? This sounds like this should
> > emit error?
> 
> The reason this doesn't emit an error is most likely due to the fact that __index can be called. I have used this in the past when I needed to store values including nil (in a set) by using a sentinel value as the key in the __(new)index method. Remember that a table lookup returning nil means the index is not present in the table so this code isn't all that surprising, even though we know nil will never index a table (directly).
> 
> If you are worried about mistyped locals not being caught, you can use a module like strict.lua to forbid undefined global access.
> Luacheck also solves this problem by statically analyzing the source code, which for most things is a better alternative to a runtime guard on the environment.

We already have mistyped locals getting caught, it's more about not catching places where the index key is nil for whatever reason, e.g.

some_module.IDX_NAME

not being defined. I recently ran into this exact use-case. We have tables with numeric indexes (because that's how they come from external data source) and we have a module which defines names for these indexes.

Unfortunately accessing some_module.NO_SUCH_IDX returns nil -> accesses the table with nil -> returns nil, which is allowed for some of the fields in the data, leading into severe head scratching.

Aki