// ...because this can be used with exactly the same meaning:if ($show_separators) { echo "<hr>\n";}?>

Converting to boolean

To explicitly convert a value to boolean, use the
(bool) or (boolean) casts. However, in
most cases the cast is unnecessary, since a value will be automatically
converted if an operator, function or control structure requires a
boolean argument.

User Contributed Notes 23 notes

Ah, yes, booleans - bit values that are either set (TRUE) or not set (FALSE). Now that we have 64 bit compilers using an int variable for booleans, there is *one* value which is FALSE (zero) and 2**64-1 values that are TRUE (everything else). It appears there's a lot more truth in this universe, but false can trump anything that's true...

PHP's handling of strings as booleans is *almost* correct - an empty string is FALSE, and a non-empty string is TRUE - with one exception: A string containing a single zero is considered FALSE. Why? If *any* non-empty strings are going to be considered FALSE, why *only* a single zero? Why not "FALSE" (preferably case insensitive), or "0.0" (with how many decimal places), or "NO" (again, case insensitive), or ... ?

The *correct* design would have been that *any* non-empty string is TRUE - period, end of story. Instead, there's another GOTCHA for the less-than-completely-experienced programmer to watch out for, and fixing the language's design error at this late date would undoubtedly break so many things that the correction is completely out of the question.

Speaking of GOTCHAs, consider this code sequence:<?php$x=TRUE;$y=FALSE;$z=$y OR $x;?>

Is $z TRUE or FALSE?

In this case, $z will be FALSE because the above code is equivalent to <?php ($z=$y) OR $x ?> rather than <?php $z=($y OR $x) ?> as might be expected - because the OR operator has lower precedence than assignment operators.

On the other hand, after this code sequence:<?php$x=TRUE;$y=FALSE;$z=$y || $x;?>

$z will be TRUE, as expected, because the || operator has higher precedence than assignment: The code is equivalent to $z=($y OR $x).

This is why you should NEVER use the OR operator without explicit parentheses around the expression where it is being used.

Just something that will probably save time for many new developers: beware of interpreting FALSE and TRUE as integers. For example, a small function for deleting elements of an array may give unexpected results if you are not fully aware of what happens:

You may get such a string from your database, if you have columns of type DECIMAL or CURRENCY. In such cases you have to explicitly check if the value is != 0 or to explicitly convert the value to int also, not only to boolean.

PHP does not break any rules with the values of true and false. The value false is not a constant for the number 0, it is a boolean value that indicates false. The value true is also not a constant for 1, it is a special boolean value that indicates true. It just happens to cast to integer 1 when you print it or use it in an expression, but it's not the same as a constant for the integer value 1 and you shouldn't use it as one. Notice what it says at the top of the page:

A boolean expresses a truth value.

It does not say "a boolean expresses a 0 or 1".

It's true that symbolic constants are specifically designed to always and only reference their constant value. But booleans are not symbolic constants, they are values. If you're trying to add 2 boolean values you might have other problems in your application.

It is correct that TRUE or FALSE should not be used as constants for the numbers 0 and 1. But there may be times when it might be helpful to see the value of the Boolean as a 1 or 0. Here's how to do it.

<?php
$var1 = TRUE;
$var2 = FALSE;

echo $var1; // Will display the number 1

echo $var2; //Will display nothing

/* To get it to display the number 0 for
a false value you have to typecast it: */

A previous comment notes the trap you can fall into with this operator. This is about its usefulness.

Both OR and || are short-circuited operators, which means they will stop evaluating once they reach a TRUE value. By design, OR is evaluated after assignment (while || is evaluated before assignment).

This has the benefit of allowing some simple constructions such as:

<?php $stuff=getStuff() or die('oops');$thing=something() or $thing=whatever();?>

The first example, often seen in PERL, could have been written as <?php if(!$stuff=getStuff()) die('oops'); ?> but reads a little more naturally. I have often used it in situations where null or false indicate failure.

The second allows for an alternative value if a falsy one is regarded as insufficient. The following example

<?php $page=@$_GET['page'] or $page=@$_COOKIE['page'] or $page=1;?>

is a simple way sequencing alternative values. (Note the usual warnings about using the @ operator or accepting unfiltered input …)

All this presupposes that 0 is also an unacceptable value in the situation.

Actually from a complete noob point of view 0 resulting in false makes sense as many languages as I have been taught consider the value 1 as true and the value 0 as false a simple boolean value.

So lets says you think you set a variable to 0 and some how or another through your code this value has implicitly become and string instead of a int or boolean. Should PHP now consider it to evaluate to false. I wouldn't think so but hey I'm a PHP noob so perhaps I'm missing why you would ever want a "0" string to evaluate to true.

For those wondering why the string "0" is falsy, consider that a good deal of input data is actually string-typed, even when it is semantically numeral.

PHP often tries to autoconvert these strings to numeral, as the programmer certainly intended (try 'echo "2"+3'). Consequently, PHP designers decided to treat 0 and "0" similarly, ie. falsy, for consistency and to avoid bugs where the programmer believes he got a true numeral that would happen to be truthy when zero.

Dunno if someone else posted this solution already, but if not, here's a useful and function to convert strings to strict booleans.Note this one only checks for string and defaults to the PHP (boolean) cast where e.g. -1 returns true, but you easily add some elseifs for other datatypes.

Since I haven't seen it posted.Here is a function that you can use if you have a need to force strict boolean values.Hopefully this will save someone some time from searching for similar.<?phpfunction strictBool($val=false){ return is_integer($val)?false:$val == 1;}?>

Simply put, it verifies that the value passed is (bool)true otherwise it's false.

Just a side note, doesn't really matters, the reason -1 is true and not false is because boolean type is treated as unsigned, so -1 would be for example, if it's unsigned int32 translate to hex: 0xFFFFFFFF and back to decimal: 4294967295 which is non-zero. there isn't really a "negative boolean". it's a binary thing. :o (since it used to be a bit and then there was only 0 and 1 as an option)

Much of the confusion about booleans (but not limited to booleans) is the fact that PHP itself automatically makes a type cast or conversion for you, which may NOT be what you want or expect. In most cases, it's better to provide functions that give your program the exact behavior you want.<?php

In other words, the only way to output the underlying zero or use it in a string is to use 'false+false' or pass it through intval(). No such tricks are required to get at the 1 that underlies true.

The whole idea of symbolic constants is that the underlying value *always* replaces them during translation, and thus anywhere you would otherwise have to use some obscure "magic number" such as 191, you can use a symbolic constant that makes sense, such as TOTAL_NATIONS.

Exactly what php gets out of breaking this rule was not explained to me.

When compare zero (0) with string it's return true by type jugling. When compare with TRUE with also the same string it's also returning true. But when comparing zero (0) with True then it's returning FALSE.