lua-users home
lua-l archive

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

Am 01.07.2013 21:05 schröbte Coda Highland:
On Mon, Jul 1, 2013 at 11:36 AM, Rena <> wrote:
On Jul 1, 2013 2:05 PM, "Roberto Ierusalimschy" <>

Couldn't a lot of ambiguity and unexpected behavior avoided by keeping
nil but introducing two new functions to the table library called
"table.has(t,key)" and "table.delete(t,key,[to])" - and dropping the
deletion via assigning nil?

At last something new and worth a discussion. Does anyone see problems/
incompatibilities/etc. with this?

(But what is "[to]"?)

Keep in mind that #t would still be undefined for arrays with holes,
but holes would be much less frequent...

-- Roberto

This seems like a good idea, but I feel like it might complicate the
internals a bit. Are you proposing that nil is able to be stored in tables,
and keys can be removed only by table.delete()? (In that case, why is #t
still undefined when holes are present? Or are nil keys no longer holes?)

Under this proposal, nils are no longer holes.

... but holes are nils. Or stated differently: There are explicit nils, which are part of a table, and implicit (deleted or never assigned) nils, which are still holes. One question is: Should accessing explicit nils invoke __(new)index metamethods?

I'd argue that if you want nils as part of tables, then go all the way, and remove nil as a default value. Throw an error when accessing a non-existing field instead. No need for strict.lua any more, yay! You could simulate the old behavior using a nil-returning __index metamethod.
Anything in between seems messy, IMHO ...

That could be useful, but also a bit confusing as it means a key set to nil
and a key that was never set (or was deleted) are different things, but both
have a nil value.

You can tell the difference with table.has().

table.has() and table.delete() would be essential functions not limited to arrays, so they should go into the base library ...

/s/ Adam