Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

i doubt that '0' or chr(48) should be given special powers, it's not intuitive for JS/Python folks that rely on common behavior.


if ($string) {# '0' will not pass here
}

$x = $string ?: 'default';# '0' will not be selected as $x


if ([0]) {# will not look into array but string will
}

chr(48) evaluates to the string "0". This is defined and documented as falsy and always has been; you're complaining about "giving" it "special powers" when what you're actually asking for is taking away properties that it has always had. It is something that PHP newbies are frequently surprised by and frequently complain about, but really turns out not to be a big deal if you pay attention to what you're doing.

This is also not JavaScript nor Python. Apologies if this means that programming in three languages means more mental work for you than programming in two.

a at b dot c dot de,

im not sure you'll read this :]

1) look at my name, it states "master", so im not a newbie. a b c.

2) argument about '0' was always special, oke, i understand, let it stay special in older versions of language. the reason of complain is about dragging this little inconsistency into future, again [0] is not checked, '0' is checked, means different behavior/logic, array vs string, which are similar constructs, you can access $string[1] and you can access $array[1]. 

3) manual. ye, manuals may contain anything. let's make chr(0) special and drag it into manual, it's not JS and Python, right.

$a = '0';
var_dump(empty($a));// true

another inconvenience i encounter with '0' is when i need to check for mixed empty values returned (falsy checks)

function func(): string|array|int {...}

if (!($a = func()) # '0' will enter which is not intended
{...}

if (!($a = func()) && $a !== '0') # this is correct variant
{...}

so it's always have to be double checks if there is a string.

1) Look, I did read it, oh Master of Gibs. Sounds like a DOOM fanatic.

2) Weigh that up against the impact the change would have on all current code.

3) The manual can say anything, but it's more useful if it's accurate.

Don't rip out something until you know why it's there in the first place. Find out the design principles behind _why_ 0 and "0" are both considered equal, empty, and cast to false.

Another inconvenience: sloppy return values makes for sloppy return value handling.


Regardless. This is not a bug. It is known documented and deliberate behaviour.

a b c

1) yes, DOOM zandronum's very good, works well. i'm creating a revolver for it will be functional soon.

2) yes, the old php code could break apart. It won't run in php v.8 anyway, so that is not a problem, right? right. A lot of code/work to do in php, i agree, much easier to play around some "new" features, but refactoring is hard as a rock.

3) not much to reply, manual is manual, ok.