Re: Undefined variables returning nil

[petah <lua@...>]

>The safety issue is that simple typos can cause bugs that aren't detected until an error is thrown by something that can't handle the nil--if indeed such a something ever encountered.

Keyed Lua tables are hashed; how do you detect a hashset lookup typo in C?

>There could very well be an uncaught nil that propagates through the program and is noticed a long time later or not at all.

Same applies to C/C++ or most other languages when a return value isn't assert()ed.

>> 3) Not handling the case of no-value is definitely an error, but that is bad programming, nothing to do with the language.
>
>One can't assume all programmers are perfect, especially non-professional ones exposed to scripting APIs in games. Certainly, none of us are perfect. Otherwise, we'd have no need for compiler errors.

C/C++ compilers that frequently warn about false uninitialized variables and ignore actual ones, which is why gcc -O3 optimization and pointer aliasing is so iffy.

>I find the philosophical defenses given so far unconvincing, with all due respect, of course.

Sorry, there's no "convincing Lua doubters lobby" :)

>I'm sure Lua's developers have considered this issue in the past, so I was curious about the reasons for not handling it; e.g., performance reasons, conceptual reasons, or otherwise.

Performance and simplicity. Lua's ref man is K&R wafer-thin and you could blink while the VM compiles. Declaring & tracking inactive table keys would be a huge overhead that doesn't fit Lua philosophy.

-- p