lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


> You can definitely store nil in a table in the sense that t[1]=nil gives
> you back nil when you read t[1].
>
>> "storing" it in a table makes the key go away
>
> This reflects our view of tables, which are containers for values.
> Keys play a secondary role. When there is no value, there's no key.
> This behavior is *not* due to some flaw in nil.

But it doesnt contain nil as a value. I'm not sure if I want to be in
the nil-as-first-class-value-group or not. But I'm sure that nil is
not a "first value" in Lua.

> One way to think about a table is that it initially contains *all* pairs
> (key,nil), for all possible keys. You wouldn't want pairs to show them all :-)

This "you can imagine everything be filled by default with nil" theme
popped up  a few time in the unfamous "arrays with holes" debatttes a
few weeks back. But it aint true.
if nil would be a first value you could do this.

t[1] = "foo"
t[2] = nil
t[3] = "bar".

i/pairs(t) should turn up (1, "foo"), (2, nil), (3, "bar"),
#t would in that case anambigously be 3 and not 1 or 3 when 2 wouldnt
been "set" to nil.  (Sorry this runs down that road again :-( )

The usual answer was, if you want to behave it that way, define your
own NULL={} and it will behave that way. But highlights, nil is not a
first-class-value. Dunno what the subtleys would be if it were, and if
I would want to go that road. But nil really is something more special
than "just a" first-class value.