Req #40692 [Nab->Dup]: Trying to use boolean as array doesn't give an error

From: Date: Mon, 08 Jun 2015 20:47:52 +0000
Subject: Req #40692 [Nab->Dup]: Trying to use boolean as array doesn't give an error
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-193218@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=40692&edit=1 ID: 40692 Updated by: cmb@php.net Reported by: smlerman at gmail dot com Summary: Trying to use boolean as array doesn't give an error -Status: Not a bug +Status: Duplicate Type: Feature/Change Request Package: *General Issues Operating System: Any PHP Version: 5.2.1 -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: > Not only is it expected it is the only reasonable thing _to > expect_. I disagree that the following behavior is the only reasonable thing to expect: false[42] // => NULL (without notice/warning) Anyhow, this is a duplicate of request #37676. Previous Comments: ------------------------------------------------------------------------ [2013-10-28 19:58:29] krakjoe@php.net As has already been explained, the behaviour exhibited is expected. Not only is it expected it is the only reasonable thing _to expect_. The only time you can expect a type to be coerced is upon passing it to the engine _for manipulation_ or upon explicit casting: <?php var_dump(error_reporting()); $a = false; var_dump($a[0]); $b = (string)$a; var_dump($b[0]); ?> If the engine had cast $a to anything on line 2, _that_ would be unexpected; if it had been done as if by magic then PHP would be unusable (because you would never know what type any variable was from one line to the next), if it had been done by the call to var_dump implicitly then var_dump would be useless for it's intended purpose. PHP is not strictly typed, end of story :) Closing request ... ------------------------------------------------------------------------ [2013-08-20 08:33:54] requinix@php.net Related To: Bug #65484 ------------------------------------------------------------------------ [2007-03-05 13:39:00] smlerman at gmail dot com Here's another test case that shows that something isn't quite right with implicit conversions. <?php var_dump(error_reporting()); $a = 12345; var_dump($a[0]); // Should cast to string or possibly array var_dump($a{0}); // Should cast to string $b = (string)$a; var_dump($b[0]); $c = (array)$a; var_dump($c[0]); ?> Results: int(8191) NULL NULL string(1) "1" int(12345) So $a isn't being converted to a string or array if you do $a[0]. It also isn't converted to a string if you do $a{0}, and I have no idea what else it could reasonably convert to. I never rely on these implicit conversions, so I have no real personal interest in whether the behavior stays the same as it is now or if the conversions are fixed, but some kind of error message, even a notice for an undefined index for something like $a['foo'], would help with debugging this kind of programmer mistake. ------------------------------------------------------------------------ [2007-03-05 00:22:42] smlerman at gmail dot com Actually, as my code shows, you do not get false, you get NULL, so it's obviously not doing a normal conversion to an array. I'm not disputing the value of the expression, since it makes perfect sense to me that the value of a non-existent variable should be NULL. In all other cases, though, it also gives a notice, which is what would be nice to have. ------------------------------------------------------------------------ [2007-03-05 00:10:28] iliaa@php.net 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 (string)false == "" "" does not have offset 0 and therefor you get a warning message. (array)false == array(0 => false); and when you access element 0 of this array you get false in return. ------------------------------------------------------------------------ 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=40692 -- Edit this bug report at https://bugs.php.net/bug.php?id=40692&edit=1

« previous php.bugs (#193218) next »