That sounds more like a setmetatable(tbl,{__index = function () error"got nil" end}) variables are harder but you can make a wrapper function that errors whenever you get nil.

I cannot even imagine how pattern matching will work when it always returns nil, not to mention tables are full of nil sometimes, it would be an incredible waste to have a table full of false instead of nil.

agreed about the property thing, though it sort of makes nil even less of a first-class value than it already is

what do you mean about pattern matching

Whenever a pattern match fails, be it string.match or string.find, it returns nil. Could it return false instead?

oh, hmm, interesting. the concern is that if you store that nil in a variable (as opposed to using it immediately for control flow) you can't get it out again if loading a variable that has been set to nil continues to behave the same way as loading a misspelled variable?

i may be falling into the trap of trying to make language x more like language y that i'm more familiar with, but i think that if a language has one or more nil values, it's usually worthwhile to draw a distinction between a variable that has one of those values and a variable that doesn't exist at all. lua gets some simplicity out of conflating these situations, because it means it doesn't need a separate mechanism for causing variables to cease to exist (you can simply assign nil), and sometimes it can simplify your code by leaving initialization implicit. but i think that the result is that lua is a lot more bug-prone

languages that do draw a distinction between not existing, and existing with a null value, include smalltalk, ruby, c, c++, python, javascript, perl, python, tcl, java, the bourne shell (except perhaps very early versions), pascal, common lisp, scheme, golang, rust, octave, and most assembly languages. conflating the two is not completely unique to lua; awk, basic, and arguably fortran 77 do that, though the nil value they give previously nonexistent variables is a numeric 0 rather than Γ

the bourne shell and by default perl also allow reads from nonexistent variables with well-defined semantics, and perl and js also allow reads from nonexistent table slots (hash and array slots) with well-defined but sometimes startling semantics. but none of these have the behavior shared by lua, awk, basic, and arguably fortran 77, where there's no way to tell the difference between a nonexistent variable and a variable that has had the null value assigned to it

so i think that lua's design choice here should be regarded as an experimental innovation, like java's checked exceptions; and, specifically, a failed one

so there would be no problem with pattern matching returning nil and storing it in a variable

I'm not concerned, mispelling a variable can be fixed via using luacheck. Something I always do via tmux + editor + {entr -c}. that or using strict.lua which sets _G's metatable __index to error out. A limitation is disallows using ENV and you have to constantly be like local foo = _G.foo, but that makes your code a bit clearer I guess.

I think having a special datatype differing between nil and null would still render the code the same, instead of using if var==nil, you're just now doing if var==null, if you're using a variable after you know a function was used and its nil you know it returned null. you can always just use { or false } if you really need to differ between nil (and waste space), that or use assert()

Also my problem with pattern matching returning nil is it breaks usage of concatenative :, as in match:""match"":match""

So if you use concatenative objects with :, make sure you never return any other type but the object itself. its what allows lpeg operator overloading to not error out in the middle of it.