Req #81456 [Com]: chr(48) is falsy

From: Date: Thu, 07 Oct 2021 02:40:31 +0000
Subject: Req #81456 [Com]: chr(48) is falsy
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-237070@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=81456&edit=1

 ID:                 81456
 Comment by:         a at b dot c dot de
 Reported by:        gib-o-master at mail dot ru
 Summary:            chr(48) is falsy
 Status:             Not a bug
 Type:               Feature/Change Request
 Package:            *General Issues
 PHP Version:        8.0.10
 Block user comment: N
 Private report:     N

 New Comment:

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.


Previous Comments:
------------------------------------------------------------------------
[2021-09-29 14:16:32] gib-o-master at mail dot ru

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.

------------------------------------------------------------------------
[2021-09-26 05:14:14] gib-o-master at mail dot ru

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

------------------------------------------------------------------------
[2021-09-19 21:50:31] gib-o-master at mail dot ru

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.

------------------------------------------------------------------------
[2021-09-19 01:49:34] a at b dot c dot de

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.

------------------------------------------------------------------------
[2021-09-18 06:19:28] gib-o-master at mail dot ru

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
}

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=81456


--
Edit this bug report at https://bugs.php.net/bug.php?id=81456&edit=1


Thread (9 messages)

« previous php.bugs (#237070) next »