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

PHP is not type strict.

Yeah, in 6 years of programming PHP, I never noticed that it isn't a strictly typed language. Trying to use an undefined offset of an array gives an error message. Trying to use a non-existant character index of a string gives an error message. So what is the boolean being converted to such that using an incorrect offset isn't an error?

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.

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.

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.

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 ...

> 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.