Re: [VOTE] Undefined Variable Error Promotion

From: Date: Wed, 16 Mar 2022 13:27:14 +0000
Subject: Re: [VOTE] Undefined Variable Error Promotion
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-117349@lists.php.net to get a copy of this message
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]

« previous php.internals (#117349) next »