Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117116
MIME-Version: 1.0
References: <620eda0f.1c69fb81.d2cb1.0846SMTPIN_ADDED_MISSING@mx.google.com>
 <5efecaef-a024-3c61-e12e-ffc342956718@gmail.com> <CAOWwgpkcnaVctXu8LgYpp_CLzx0QySbV87ibRqy0aD6qqHmsxA@mail.gmail.com>
In-Reply-To: <CAOWwgpkcnaVctXu8LgYpp_CLzx0QySbV87ibRqy0aD6qqHmsxA@mail.gmail.com>
Date: Tue, 22 Feb 2022 06:25:54 -0600
Message-ID: <CACL3jgOchoE-ntNLgUu-Hmqv1JMgqJDj4oX8oWnwDfOKp3_iQg@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: Rowan Tommins <rowan.collins@gmail.com>, Mark Randall <marandall@php.net>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d6b19205d89a734f"
Subject: Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
From: nwallace@fyberstudios.com (Nick Wallace)

--000000000000d6b19205d89a734f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=C3=A9vr. 2022 =C3=A0 12:24, Rowan Tommins <rowan.collins@gma=
il.com> a
> =C3=A9crit :
>
> > 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" sectio=
n
> > 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 goo=
d
> > 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 us=
e
> > 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[] =3D 42;) does NOT currently give an
> > undefined variable Warning
> > - variable variables, e.g. "$b =3D '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 mu=
ch
> 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 addin=
g
> any other Error at places that currently don't throw any warnings, then i=
t
> 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
>

--000000000000d6b19205d89a734f--