What are the drawbacks of allowing implicit boolean/integer conversions?

Question

Some languages (C, C++, JavaScript, Python) allow one to use integers as booleans and vice versa:

int x;
if (x) // Equivalent to: x != 0
    y();

Or:

int x = 10 + (y > 10); // Equivalent to: y > 10 ? 11 : 10

However, other languages such as Java, C#, and Swift disallow this. They do not even allow explicit casting and force users to explicitly write != 0 and ? 1 : 0 to cast from integer to boolean or boolean to integer respectively.

What is the rationale for disallowing this? Allowing integers and booleans to freely convert allows certain logic to be expressed much more concisely, such as that to determine if exactly N conditions are true. So what are the drawbacks?

Answer 1

There is a particular drawback of allowing implicit conversions (aka coercions*) from bool to int in dynamic languages such as Python, where many other types have coercions to bool. Coercions are generally not transitive, meaning that e.g. allowing coercion from list to bool and coercion from bool to int, does not imply that there is a coercion from list to int, let alone that this coercion would be consistent with the composition of the other two.

So consider code like this:

def exactly_two(x, y, z):
    return x + y + z == 2

The exactly_two function uses bool-to-int coercion to test whether exactly two of the conditions are true. However, this means it relies on the arguments being bool values; yet in most places where a condition is tested, the condition is allowed to be some other type which coerces to bool. Consider:

a, b, c = [1, 2, 3], [], [4, 5]
print(exactly_two(a, b, c))

The desired behaviour of the above program is to print "True", since exactly two of the given lists are truthy (non-empty). However this program actually prints "False", since x + y + z is a sum of lists, not a sum of Booleans coerced to integers.

This can get even messier when the coercion from int to bool is also considered:

p, q, r = 2, 3, 0
print(exactly_two(p or q, p and r, q and r))

In Boolean logic, the above program should print "False" since only the condition p or q is true. However, in Python the condition 2 or 3 doesn't evaluate as True, it evaluates as 2. Then the condition x + y + z is 2 + 0 + 0, and hence the program prints "True".

---

^{*Technically, Python doesn't coerce from bool to int, rather in Python bool is a subtype of int and the Liskov substitution principle applies. But I'll say "coercion" for the sake of brevity and language-agnosticism.}

Answer 2

The main drawback of allowing implicit boolean/integer conversions is, it makes it impossible to prevent errors that result from confusion of a boolean and an integer.

Next time you confuse the order of the arguments to a function that takes an integer and a boolean, instead of getting a nice error message that points out what you did wrong, it will compile and do something unexpected.

It is a fairly important drawback. If the conversion is infrequently used, forcing the user to be explicit is a good thing. Besides, != 0 and ? 1 : 0 are not that long to write.

Answer 3

Booleans may not just be 1 or 0

Much of this depends on the underlying representation of the value. My particular experience of this is with C.

Before C99, there was no boolean type, only integers treated as booleans. Boolean data of course can only be 0 or 1; but an integer type can clearly have more states. Consider the code

if (x == TRUE)
    do_something();

do_another_thing();

if (x == FALSE)
    do_something_else();

Clearly if x is boolean then one or other function should be called. But if x (as an integer) has been set to 2 for example, then neither function will be called! For that reason, coding standards often required the form

if (x)
    do_something();

do_another_thing();

if (!x)
    do_something_else();

so that all non-zero values would be covered by the first case. (I should say here that this is not just a theoretical issue. I have personally seen this bug happen, and it was really hard to find!)

C99 solved this particular problem by adding a bool type, where if (x == TRUE) succeeds for any non-zero value of x. However you can still go wrong with this. Most notably, your "efficient" method of summing bools to find how many values are set true is going to fail badly if any are stored as integer values greater than 1.

More interestingly still, you can't even quantify how badly that method will fail. C merely requires bool to have at least 2 states, and the compiler is perfectly free to store this in a single bit, a byte, or a 32-bit word. I can point you to compilers/hardware which would give you all of these cases. I've personally stumbled over a bug where two different processors accessing shared memory represented bool as a byte on one side and a 32-bit word on the other, so I actually had to replace the "better" bool definitions in the shared memory structures with fixed-size integers which both sides could agree on.

This is all somewhat specific to C, of course, but the principles apply to most languages. Ultimately your boolean value needs to be stored somewhere, and if execution speed is an issue then your language may well use a single word per boolean value so that your code runs faster. Of course this may not be as applicable to interpreted languages such as Python, where the language is already slow enough that a small extra delay is not significant.

A class of bugs can be eliminated

Bugs happen, let's be real about that. One sign of clearly-written code is that it can be easier to find bugs when they happen. And one sign of a language that helps you is where a class of bugs can be eliminated by a language feature.

If you got the wrong variable in your if (x) check (and hands up any coder who hasn't? no hands? good, we're all in the real world here) then you've got a bug. If you accidentally use the name of another boolean variable then your code will build, and it will misbehave, but at least it will misbehave in a predictable, repeatable way.

If you accidentally use the name of an integer variable though, with a language which gives you implicit conversions, all the issues above could come out of the woodwork. If your language gives you an implicit zero/non-zero comparison then at least some of those problems go away, but reproducing it is likely to be hard. If your language stops these bugs at compile time, an entire class of bugs will simply go away. This is generally a good thing (assuming you can potentially handle a bit of inefficiency in the code anyway).

Answer 4

In addition to all the other fine answers, Boolean coercions are not consistent across languages:

• Zero (0) is considered falsy in Python and JavaScript, but truthy in Ruby.

• The empty array ([]) is considered falsy in Python, but truthy in JavaScript and Ruby.

• Not-a-number (NaN) is considered falsy in JavaScript, but truthy in Python and Ruby.

Note that the only two falsy values in Ruby are false and nil. That means everything else is truthy. Python and JavaScript have longer lists of falsy and truthy values. Python and C++ allow operator overloading to define custom coercions to bool.

I personally agree with the strict, explicit approach to Booleans that is enforced by Java, C#, and Rust.

Answer 5

One particularly bad issue with int to bool conversions is that if you have an expression based language, the assignment x=7 will typically return 7. This makes if x=7 valid syntax, which is really bad since this is a common typo for if x==7.

Answer 6

There are some common errors that result from integer to boolean conversions.

One of the most common among C beginners is the strcmp() function. As a comparison function, it's easy to assume that it returns a boolean, with the truthy value meaning the strings are equal. But it's actually tri-valued: negative and positive for unequal (indicating whether one string is lexicographically lower or higher), and zero (C's falsey value) meaning equal.

Another class of functions with a similar problem is functions that search a string or array and return the index of a match. Since most languages use zero-based indexes, 0 is a valid index of a successful search, and some other value must be returned to indicate failure. JavaScript returns -1; PHP returns false (you must use the strict comparison operator to avoid automatic coercion that makes 0 == false); Python returns -1 from some functions and raises an exception from others. But again, it's a common mistake to treat the searching function as boolean.

Answer 7

There might not be a sensible, unambiguously correct conversion

The popular Numpy third-party library for Python provides a clear case study for this possibility. Because Python is dynamically typed, it is forced to accept code that would invoke an implicit conversion. Early on, the language implementers chose to allow such conversions to be attempted, and specified that types could define this conversion using the __bool__ "magic method".

This is a trade-off made for pragmatic reasons; in many other places, Python refuses implicit conversions and remains fairly strongly typed (for example, it does not allow concatenating an integer to a string with the semantics of implicitly using a string representation of the integer). In the case of conditional logic, the Python implementers apparently felt that requiring conversions all the time to avoid exceptions would be too tedious. However, the Numpy implementers found a need to refuse this convenience.

Numpy defines an array type that provides a bunch of operator overloads that implicitly "broadcast" operations - comparing two identically-shaped arrays element-wise, or repeating the comparison along one or more axes if the array shapes are "compatible".

In particular, for two arrays a and b of the same shape, the == operator (via overloaded __eq__ method) will compare each pair of corresponding elements, and return a new array of booleans of the same shape with the comparison results in the corresponding places:

>>> import numpy as np
>>> a = np.ones((3,3))
>>> b = np.ones((3,3))
>>> a[:,1] = 0
>>> b[1,:] = 0
>>> a
array([[1., 0., 1.],
       [1., 0., 1.],
       [1., 0., 1.]])
>>> b
array([[1., 1., 1.],
       [0., 0., 0.],
       [1., 1., 1.]])
>>> a == b
array([[ True, False,  True],
       [False,  True, False],
       [ True, False,  True]])

This sort of functionality is considered very useful, and a huge part of the reason why Python enjoys the popularity it does today with data scientists.

So the next question is, what should we expect to happen for if a == b:, or in a conditional expression like 'y' if a == b else 'n'?

Python has built-in fallback logic for comparisons - normally, everything that isn't explicitly falsy via an overloaded __bool__, is truthy (via object.__bool__). However, Numpy explicitly overloads __bool__ for arrays to raise an exception unless the array has exactly one element. (It used to consider zero-element arrays falsy, but current versions also raise an exception here.)

Why?

This is in accordance with the Zen of Python: "In the face of ambiguity, refuse the temptation to guess".

Think about it: if a == b: comparing two Numpy arrays, presumably, probably meant to check whether every corresponding pair of elements is equal. But the result of a == b is just an array of boolean values. Meanwhile, if c:, where c was an already existing array of boolean values, probably means to check whether any element is True. There is no way for the __bool__ operator overload to know which was meant, because it does not have access to the AST.

Moreover, such logic is often wrong-headed anyway. Commonly, people want the code inside the block to describe work to do with a single pair of elements, and the code author wants that calculation to be broadcast - but Numpy simply cannot work this way. There definitely isn't any operator to overload, because if is a statement rather than an expression. But even the conditional expression form doesn't work, and Numpy couldn't make it work if they wanted to. One might think that 'y' if a == b else 'n' ought to produce an array of strings, but even if it could work, this would be deeply magical and many Pythonistas would complain about it being complex and surprising. (Even using the x if y else z conditional expression is not universally accepted; but it would be especially hard to accept that the result might be neither x nor z!)

Instead, that job requires a different tool, such as numpy.where, or using the a == b result as a mask for another array, etc.

See also the corresponding canonical on Stack Overflow about the error message generated by the attempted implicit conversion - especially my answer there.

Answer 8

Many of the advantages associated with allowing implicit conversion could be achieved by instead providing convenient means of handling the scenarios where such conversions would be most useful. If one wants to branch if foo and bar have any bits in common, being able to write an expression where foo and bar are the only things that look like values, e.g. if (foo & bar) is nicer than having to do something like if ((foo & bar) != 0). If, however, there were an operator which would accept two integers and return a Boolean, that would make intent even clearer than the form using implicit integer-to-Boolean conversion.

Additionally, if a language had an operator that behaves like Javascript's && operator, yielding the second operand's value when the first is "truthy", then an expression like (a==b) | ((x==y)*2) could be written as ((a==b) && 1) + ((x==y) && 2). I'm not sure && would be the best choice for that operator, but having an operator with such semantics would accommodate the second most common use case for implicit Boolean/integer conversions.

An as-yet unmentioned downside to opening up arbitrary integer-to-Boolean conversions in languages which support bit fields, the semantics of Boolean bitfields would differ from those of other types. For example, given:

struct foo {unsigned char bit:1; _Bool boo:1;} it;
void test(int value)
{
  it.bit=value;
  it.boo = value;
}

invoking test(2) would set it.bit to zero but it.boo to 1.

Answer 9

If int implicitly converts to boolean I can't write x ?: 3 where x is maybe<int>, and ?: is null coalesce operator. This ends up being ambiguous between coalesce null to 3 and coalesce 0 to 3. (GCC has the latter operator: 0 ?: 3 does in fact produce 3. The operator is more useful when the left side is a pointer.)

If you make the choice maybe<int> -> bool, you then have to choose between 0 is kept or coalesced. If you choose coalesced, your type system ultimately requires backtracking to determine the type of a chained coalesce (maybe<int> ?: a : b is hard to find the type of if b is a ternary). If you choose kept, you then have to decide what maybe<int>(0) ? a : b does. If you choose a, you end up with a big difference between maybe<int> and int such that the program becomes hard to read if you have the var/auto mechanism for getting type of variable from its right side (which is typically a function call return); and if you choose b, you have a behavior difference between coalesce and ternary.

If T[] (array) collapses to bool; it's ambiguous between maybe<[]> and {} (empty array); empty array collapsing to bool as false always bugged me for this very reason, but collapsing to bool as true is totally unexpected. (Yes I really did mean to write collapse as this converts a vector to a scalar.)

You really don't want maybe<bool> converting to bool; bug rats nest. If you think you need it, consider allowing if(maybe<bool>) to be valid as-is; that is if, while, and for take maybe<bool> directly. This will, however, make for a small headache if you also have maybe<T> converting to bool as the standard way to check if a maybe has a value, which will typically exist in languages that do implicit conversions to bool.

Answer 10

The reason to not allow it is that booleans are not numbers. Just like pointers are neither numbers nor booleans. So without 50 years of prejudice from C programming, there is no sane reason why a cast, either implicit or explicit should be allowed.