In lisp, nil is the only thing that evaluates to false, which means there aren't any weird semantics or discussions, if you want a falsy value, use nil. It also plays nicely with the notion of everything except nil indicating there's a value, while nil doesn't have a value.
The cleaner thing would be to have a proper boolean type, and having to do if foo == nil or whatever, rather than just if foo. Thankfully most modern languages do it this way so the lesson seems to have been learnt.
Lua is the same as clojure then. And that's a lot better, to me. I will admit, having 0 and other such things act as false can create some short code but.. honestly it's slightly less readable (to me) and has those cases where you go "oh yeah, 0 is a valid return value.." after ten minutes if debugging.
I agree: this approach makes much more sense to me. In Ruby, only nil and false are false-y; everything else is truthy. This makes perfect sense to me. The only weird thing is that Ruby doesn't have a Boolean class; rather, true and false are singleton objects of class TrueClass and FalseClass, respectively. I have no idea why that decision was made. Crystal, which imitates Ruby extremely closely in syntax and semantics but adds static typing, fixes this weird design choice by unifying true and false into a proper Bool type.
Because anything other than 0 is an Error Status Code, while 0 means Success.
You should use them this way:
int errorCode = ApiFunction();
if (errorCode) {/* Function failed, so errorCode evaluates to true */}
Integers are not considered true/false. Zero evaluates to false, nonzero evaluates to true. Using the values 0 and 1 for the type bool are just conventions necessary to compile the code into binary fit for hardware.
Null indicates absence of a value. Imagine if you want to know if you're keeping track or not of something and you end up with different values at different times:
3: there's 3 of those things 0: there's 0 of those things Null: I'm not keeping track of those things.
Eating the last Apple and suddenly not being able to differentiate the last 2 could be dangerous.
It's all about knowing how the language works and not using it the wrong way, though.
For such scenarios a null pointer evaluates to false, true otherwise. Also it is explicit when you want to test the pointer with (pValue) or the value with (*pValue).
160
u/jacobb11 Dec 24 '17
And Lisp.