The rationale behind Falsy values [closed]

Question

I'm wondering what the arguments for/against Falsy values are. On what principles would you decide to add or exclude them from a language? Are there any problems you could see them causing off-hand?

For users of languages that support Falsy values:

• Where specifically have you used them to your advantage?
• Where have you had unpleasant run-ins with them?
• Are there any rules or finer points in your language/project/team about where it's appropriate or inappropriate to use them?

For users of other languages:

• Have you ever seen a situation where you've thought "I wish I could use a Falsy value here"?

I'm tagging the question haskell and python because AFAIK those two represent opposite ends of the spectrum (Haskell demanding Bools when you use if, and Python treating None and some "empty" values as Falsy), but feel free to talk about your experience from other languages. Just mention where on the spectrum they stand.

Answer 1

I use them to my advantage in Javascript all the time. In Javascript, the falsy values are undefined, null, false, NaN, 0 and ""

It is just much easier to read:

if( !str ) {

}

instead of

if( str == null || str.length() == 0 ) {

}

or str == null || str.equals("") or bunch of other just as bad equivalents that you need to use in Java.

I do recall an instance where I was bitten by this, doing x || y, when a certain falsy value was desirable as x. But this is very rare.

---

However, the check is relatively sane in Javascript. Consider PHP, where additionally the string "0", an empty array or, and I quote:

SimpleXML objects created from empty tags

are considered falsy values. Also, NaN is truthy in PHP! So in this mess of completely arbitrary inconsistency, I wouldn't find the truthy/falsy concept as good.

Answer 2

Haskell too has the concept of falsy and I use them all the time.

Assume I have a handful of values and I need to fail if any one of those values are "false" (bools would be false, lists would be empty...). I can use the Maybe monoid to easily check if any of them are considered false based on their type.

True, the "if" statement in Haskell still only allows a boolean test condition, But Haskell makes it easy enough to create your own control structures to circumvent the problem.

The key is that in Haskell they are completely type checked so you know exactly what's happening. I've longed for them in C# but got around it by just explicitly checking for "false"

Answer 3

In Python it's more of a something vs nothing concept, and it's incredibly convenient, plus much more readable, to have one's custom classes set to show as nothing (False) if they don't have a meaningful value when used in boolean tests.

Nearly all my own classes support it (lot's of container-type classes).

Answer 4

The problem with "falsy" values is that they inevitably lead to ambiguities between in- and out-of-bounds responses: cases where an operation returns a "falsy" value that could mean either failure to produce an answer or success at producing an answer whose value is the "falsy" value.

One familiar example would be Java's Map<K,V>.get(K key) method, which returns null in two situations:

1. The map doesn't have an entry for the key you asked for.
2. The map has an entry that maps that key to null.

Contrast Haskell, where not only are a and Maybe a different types, but also Maybe (Maybe a) and so on. In Haskell, if you need to (and most of the time you don't), you can distinguish between Nothing ("outer" failure) and Just Nothing ("inner" failure).

Answer 5

On what principles would you decide to add or exclude them from a language?

I don't think that's the right question. Every language designer has something in mind when they design their language, and that often will dictate some of the answers. For example, if you are designing for type-safety, then you won't allow numbers to be true or false. If you are designing for "easy scripting", you will allow lots of short-cuts.

For example, SQL treats NULL and false as so different that you have to use different operators on them ("is null" vs "= false"). Ruby thinks 0 is true, but Perl thinks it's false.

In Ruby, the set of things that are false is small enough to be easy to remember (Just false and nil).

Where specifically have you used them to your advantage?

When picking up default values from various places:

my_name = env.name || command_line_swich.name || default_name
value = config['value'] || raise("no value found")

Are there any problems you could see them causing off-hand?

Yes. In Perl, doing the above with numbers is a bad idea (because 0 could be valid, but will be ignored because it's false). Even in Ruby, it breaks when you have boolean values.

Are there any rules or finer points in your language/project/team about where it's appropriate or inappropriate to use them?

Not really. We use them wherever we can get away with it, which proves their value.