Re: [RFC] Undefined Variable Error Promotion
| From: | Nick Wallace | Date: | Tue, 22 Feb 2022 12:25:54 +0000 |
| Subject: | Re: [RFC] Undefined Variable Error Promotion | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-117116@lists.php.net to get a copy of this message | ||
I have tried to no avail to be removed from this list. So I will just spam
this until I am removed.
On Tue, Feb 22, 2022, 3:15 AM Nicolas Grekas <nicolas.grekas+php@gmail.com>
wrote:
> Le ven. 18 févr. 2022 à 12:24, Rowan Tommins <rowan.collins@gmail.com> a
> écrit :
>
> > On 17/02/2022 23:28, Mark Randall wrote:
> > > I present:
> > >
> > >
> > > https://wiki.php.net/rfc/undefined_variable_error_promotion
> >
> >
> > It would be good to have a "Scope" or "Unaffected Functionality"
> > section
> > here, because there are a number of closely related things which were
> > also raised from Notice to Warning in 8.0:
> >
> > - undefined array keys
> > - undefined object properties
> > - array access on a non-array
> > - property access on a non-object
> >
> > I think it is sensible to discuss those separately, but it would be good
> > to make that clear.
> >
> >
> > Similarly, it would be good to have more discussion of what "accessing"
> > means, as the current examples are quite narrow, only showing direct use
> > and the ++ operator. Other functionality potentially affected:
> >
> > - passing the variable to a function, presumably excluding by-reference
> > parameters which don't currently warn
> > - all the combined assignment operators -
> >
> > https://www.php.net/manual/en/language.operators.assignment.php
> > - the array append operator ($a[] = 42;) does NOT currently give an
> > undefined variable Warning
> > - variable variables, e.g. "$b = 'a'; echo $$b;"
> > - the compact() pseudo-function
> >
> > There's probably others that I've missed.
> >
>
> I 100% agree with that. An "Unaffected Functionality" section would be much
> welcome.
>
> I would add to the list: isset($foo) when $foo is first seen.
> (To me this should not throw anything, like for uninitialized properties.)
>
> If the RFC is about promoting the current warnings to Error without adding
> any other Error at places that currently don't throw any warnings, then it
> could be useful to say so. And if the RFC is going to propose to throw
> Error at places that are currently warning-less, the list should be
> explicit.
>
> I very much call for an implementation to be provided before starting any
> vote on the topic btw.
> This is typically the kind of topic where getting into the actual code
> might help spot edge cases.
>
> Thanks for the RFC btw!
>
> Nicolas
>