Re: Array dereferencing of scalars

Hi all, ----- Original Message ----- From: "Christoph Becker" Sent: Tuesday, June 09, 2015

Yasuo Ohgaki wrote:

I fully agree that current behavior could be used meaningful ways. However, <?php $foo = 42; $foo['bar']; // => NULL $v = NULL; $v[0][1][2][3][4][5][6][7][8][9]; // NULL this code is semantically wrong and I would like to have error/exception for such erroneous codes. It's inconsistent with array object, too. Raising exception/error is correct behavior for types that aren't array. To avoid errors, users should use isset()/is_array()/etc.

I agree that the code is not clean, and that an isset check is appropriate, particularly as one could do: $v = NULL; $v[0][1][2][3][4][5][6][7][8][9] ?? NULL; // NULL

Forgetting the NULL case for a sec... With: $v = []; $v[0][1][2][3][4][5][6][7][8][9]; How/why are we going from 1 Notice to 10?! With: unset($v); $v[0]; Why from 1 Notice about the undefined variable, to 2? That's totally new, and it really doesn't make sense to make any more noise after you've already been told about the variable. (Same after the first undefined array offset, too, but this makes the point more obvious.) That's why I'm saying, you can only really change it for non-NULL scalars that have an actual value, to keep this other stuff the same, and sane. I don't really see a semantic issue with the NULL case, either, unlike other scalar types.

Since we have debate for this PR, this PR would be good for RFC targeting PHP 7.1.

It seems to me that raising an exception or throwing an error (instead of a notice) could be too much of a BC break for a minor version.

Just wondering, in the exception case, does that mean 10 exceptions also (one for each dimension)...?

-- Christoph M. Becker

- Matt