Hi internals,
I've done some bug report gathering on essentially the following behaviour:
$a = 123; var_dump($a[1]); // "NULL"
$b = true; var_dump($b[1]); // "NULL"
$f = fopen('file', 'r'); var_dump($f[1]); // "NULL"
$n = null; var_dump($n[1]); // "NULL"
Bug reports:
https://bugs.php.net/bug.php?id=37676
https://bugs.php.net/bug.php?id=40692
https://bugs.php.net/bug.php?id=62769
https://bugs.php.net/bug.php?id=64194
https://bugs.php.net/bug.php?id=65484
From the comments it seems that there's some disagreement within the group,
for example:
Nikita: "I would tentatively classify this as a bug."
Tony: "Reclassified as feature request.."
Xinchen: "there was a similar bug report of this behavior, and I seems made
a fix for it."
Ilia: "this is not a bug." x 2
Joe: "it is the only reasonable thing to expect"
From my understanding, developers are expecting to see notices when this
happens, something like "Cannot use integer/boolean/resource/null as array
in %s on line %d"; I think they're okay with the fact that the end result
will still be "NULL", though.
The list()
operator has since complicated matters; if we would indeed
introduce notices as requested, the following code would cause issues:
$array = [1, 2, 3];
while (list($key, $value) = each($array)) {
echo "$key = $value\n";
}
The return value of each()
- as it has reached the end of an array - is
false
, so the above code would show two notices. Unfortunately, we must
assume that all code in the manual are actually used and so it would surely
break stuff when introduced.
We could mitigate this issue by having each()
return null
instead and
introduce notices for all other scalars, but this code is not unlikely:
while (($data = each($array)) !== false) {
echo "${data[0]} = ${data[1]}\n";
}
So my question is, how should we handle this? Close all bug reports and add
something to the documentation? Allow array dereference only on booleans
and null
?
Best,
Jack
Hi internals,
I've done some bug report gathering on essentially the following
behaviour:$a = 123; var_dump($a[1]); // "NULL"
$b = true; var_dump($b[1]); // "NULL"
$f = fopen('file', 'r'); var_dump($f[1]); // "NULL"
$n = null; var_dump($n[1]); // "NULL"Bug reports:
https://bugs.php.net/bug.php?id=37676
https://bugs.php.net/bug.php?id=40692
https://bugs.php.net/bug.php?id=62769
https://bugs.php.net/bug.php?id=64194
https://bugs.php.net/bug.php?id=65484From the comments it seems that there's some disagreement within the
group,
for example:Nikita: "I would tentatively classify this as a bug."
Tony: "Reclassified as feature request.."
Xinchen: "there was a similar bug report of this behavior, and I seems
made
a fix for it."
Ilia: "this is not a bug." x 2
Joe: "it is the only reasonable thing to expect"From my understanding, developers are expecting to see notices when this
happens, something like "Cannot use integer/boolean/resource/null as array
in %s on line %d"; I think they're okay with the fact that the end result
will still be "NULL", though.The
list()
operator has since complicated matters; if we would indeed
introduce notices as requested, the following code would cause issues:$array = [1, 2, 3];
while (list($key, $value) = each($array)) {
echo "$key = $value\n";
}The return value of
each()
- as it has reached the end of an array - is
false
, so the above code would show two notices. Unfortunately, we must
assume that all code in the manual are actually used and so it would
surely
break stuff when introduced.We could mitigate this issue by having
each()
returnnull
instead and
introduce notices for all other scalars, but this code is not unlikely:while (($data = each($array)) !== false) {
echo "${data[0]} = ${data[1]}\n";
}So my question is, how should we handle this? Close all bug reports and
add
something to the documentation? Allow array dereference only on booleans
andnull
?
The alternative is treating list() as the special case and suppressing the
error there. I'd prefer this over allowing bool/null to be dereferenced
silently in the general case, since it would keep the special handling
where it belongs - I.e. where the conflict is.
Best,
Jack
Hi Chris,
Hi internals,
I've done some bug report gathering on essentially the following
behaviour:$a = 123; var_dump($a[1]); // "NULL"
$b = true; var_dump($b[1]); // "NULL"
$f = fopen('file', 'r'); var_dump($f[1]); // "NULL"
$n = null; var_dump($n[1]); // "NULL"Bug reports:
https://bugs.php.net/bug.php?id=37676
https://bugs.php.net/bug.php?id=40692
https://bugs.php.net/bug.php?id=62769
https://bugs.php.net/bug.php?id=64194
https://bugs.php.net/bug.php?id=65484From the comments it seems that there's some disagreement within the
group,
for example:Nikita: "I would tentatively classify this as a bug."
Tony: "Reclassified as feature request.."
Xinchen: "there was a similar bug report of this behavior, and I seems
made
a fix for it."
Ilia: "this is not a bug." x 2
Joe: "it is the only reasonable thing to expect"From my understanding, developers are expecting to see notices when this
happens, something like "Cannot use integer/boolean/resource/null as
array
in %s on line %d"; I think they're okay with the fact that the end result
will still be "NULL", though.The
list()
operator has since complicated matters; if we would indeed
introduce notices as requested, the following code would cause issues:$array = [1, 2, 3];
while (list($key, $value) = each($array)) {
echo "$key = $value\n";
}The return value of
each()
- as it has reached the end of an array - is
false
, so the above code would show two notices. Unfortunately, we must
assume that all code in the manual are actually used and so it would
surely
break stuff when introduced.We could mitigate this issue by having
each()
returnnull
instead and
introduce notices for all other scalars, but this code is not unlikely:while (($data = each($array)) !== false) {
echo "${data[0]} = ${data[1]}\n";
}So my question is, how should we handle this? Close all bug reports and
add
something to the documentation? Allow array dereference only on booleans
andnull
?The alternative is treating list() as the special case and suppressing the
error there. I'd prefer this over allowing bool/null to be dereferenced
silently in the general case, since it would keep the special handling
where it belongs - I.e. where the conflict is.
The problem is that list()
is not an opcode per se, but rather a code
generator; it generates assignment opcodes for each specified variable, so:
list($key, $value) = each($array);
Gets compiled into:
$tmp = each($array);
$key = $tmp[0];
$value = $tmp[1];
From what I gather, what you have proposed only has a chance of working if
the compiler could be told to perform the assignment and silently discard
any issues that arise from doing an array dereference on something that's
not an array (or object that looks like an array).
Perhaps that's possible, I'm not sure :)
Best,
Jack
--
Tjerk