The 'I want nils in tables' problem (or is it?), random thougths and an entirely different proposal

[Sergey Zakharchenko <doublef.mobile@...>]

Hello,

I've seen quite many discussions on the topic, and due to the recent
5.4 work1 announcement and the caps-lock posts that followed I thought
I could throw in my two copecks. The opinion and/or proposal may be
stupid but I haven't seen them yet so for completeness, here they go.

Background: I must admit that I've never needed nils in my tables. I'm
quite fine with table packing with {n=select("#",...),...} and
unpacking/iterating respecting n for argument-passing needs. I'm still
using (heavily patched) Lua 5.1.

In any type system, there tends to be an hierarchy of 'definedness'
for values. E.g. in current Lua, a value which is true could mean
'OK', false could mean 'not OK', and nil could mean 'I don't know what
you're talking about'. Some people want to fit 'I know what you're
talking about but I am not decided' in the picture. These people also
tend to be familiar with JavaScript, or at least JSON. What they're
looking for is something *more*, not *less* defined than nil. That's
why the 'undef' proposal looks like a bit backwards to them. You're
(not literally, insert all caps mentioned above) trying to add
'undefined' from JavaScript to Lua, but nil already *is* the undefined
you're looking for.

There are Lua libraries in the wild which work with JSON, and they
face the 'nil cannot be a real table value' problem. The solutions
include one which I'm in favor of: presenting JSON null as a light
userdata with value NULL (the C NULL pointer, which usually happens to
be 0). There is little other use for such a light userdata (e.g.
nobody in their right mind would use it for some sort of a token while
they could just point to some private function/variable of theirs).
What's missing from this picture is that this userdata remains true
when treated as a boolean. So what I propose is to add such a light
userdata to the globals (as e.g. 'null'?) and allow it to be false in
a boolean context.

OT: nils as values are peanuts, wait until they want nils as *keys*...

Best regards,

-- 
DoubleF