On 15/03/2022 23:02, Patrick ALLAERT wrote:
This is not far from the reason why I voted "no".
I am not against the fact this warning becomes an error per se. I am just
not very fan of cherry-picking an individual kind of problem (read:
notice/warning/error/...) and changing it without a more global frame.
I have also voted no for similar reasons: the scope of this RFC appears
to be "all the places that are convenient", rather than "all the places
that are covered by the claimed rationale".
I think it is sensible to raise an error for the kind the kind of
"undefined foo" that is almost certainly a typo. I think we should be
more cautious about the kind that could be lazy but intentional dynamic
access. I would have voted Yes to an RFC which defined its scope in such
terms.
The language does not currently make that distinction consistently, and
I don't think we should be planning an error on a basis as vague as
"wherever we currently have a warning".
For instance, in-place increment is covered, but array append is not:
$undefined++; // Warning, planned Error
$undefined[] = 1; // completely silent
Similarly, variable-variables are covered, even though they are more
similar to array keys, which are not:
$foo = 'undefined'; $$foo++; // covered by RFC
$array = []; $key = 'undefined'; $array[$key]++; // not covered by RFC
None of this is even mentioned in the RFC, let alone justified.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
