Exactly. The only problem with nil/false is that people use these values incorrectly. nil is by no means synonomous with false, so it makes sense that nil ~= false. Being false and not defined are two very different states. And the proposal that all types should have true/false values seems strange to me, as anything with true/false evaluations is by definition a boolean, which Lua of course already has. Would it make sense at all if "" == 0? So long as you take the convention that nil means something like "undefined" then everything makes sense the way it is. assert (bar ~= nil); if bar == true then print "true"; else print "false"; end; -----Original Message----- From: lua-bounces@bazar2.conectiva.com.br on behalf of Adam D. Moss Sent: Thu 3/2/2006 10:59 AM To: Lua list Subject: Re: Different shades of false Alen Ladavac wrote: > Why not getting rid of false altogether? I guess because nil and false just aren't the same thing with different types. For comparison purposes they pretty much serve the same function, but as table values (and keys!) they're semantically very different things, not just differently typed. (I use 'false' values in tables where a 'nil's implicit removal of the corresponding key would not mean what I want - particularly in configuration management where setting an option to false is different from setting it to nil, where the latter case simply says that this configuration option doesn't exist and is therefore undefined/defaulted.) --adam
<<winmail.dat>>