Re: tables holding nil

[Cosmin Apreutesei <cosmin.apreutesei@...>]

>> I thought print(xxx) tries getfenv(1)['xxx'], and not getfenv(1)[nil].
>
> Yes, pretty much. But my point was: do you want print(xxx) to abort with
> an error?

No, but I don't understand how it could. I mean how would tbl[nil]
throwing an error affect print(xxx)? Does print(xxx) access the nil
key of any table? I thought it just tries the 'xxx' key of getfenv().
Maybe you meant print(t[xxx])? That would indeed access the nil key of
a for an undefined variable xxx. In that case, yes, it should throw
and error.


Allow me to restate my puzzle: Currently, metatables allows me for
virtualizing the nil key, but just as a read-only key. I asked what is
the logic behind this since I was expecting either:

 1) __index and __newindex is not called when reading/writing the nil
key --> the nil key is not a valid table key and therefore there's
nothing to virtualize about.

 2) __index and __newindex is called when reading/writing the nil key
--> nil is virtualizable, even if it's not a valid key for real
tables; breaking next() doesn't matter in this case since virtual
tables would override __next() or __pairs() anyway or provide their
own iterators.

Now regardless of metatables, tbl[nil] not throwing an error means
that nil is indeed a valid table key that just has the default value
nil, just as any other key has. If so, I should be able to write any
value to it. Otherwise I expect an error. Currently, for an undefined
variable xxx, x=a[xxx] works but a[xxx]=x doesn't. It just seems
inconsistent, that's all.