Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119118
MIME-Version: 1.0
References: <CAMXcktOiFH-0f0PG9cKkkVaczjNLSzQzzPUBcoLyn54X=c74og@mail.gmail.com>
 <D494A14E-0733-406B-844E-DD2D3FBB7EB4@php.net>
In-Reply-To: <D494A14E-0733-406B-844E-DD2D3FBB7EB4@php.net>
Date: Tue, 13 Dec 2022 07:53:22 -0500
Message-ID: <CAMXcktNEW9ZyvzOdseaz3yu7zLAKq5LrF74=FAk62BTbF+0qFQ@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000da95d105efb51b1d"
Subject: Re: [PHP-DEV] Revisiting RFC: Engine Warnings -- Undefined array index
From: dliebner@gmail.com (Dan Liebner)

--000000000000da95d105efb51b1d
Content-Type: text/plain; charset="UTF-8"

> No, code doesn't break. It now shows a warning instead of an error. There
is no behavioural change.
It breaks my app. Does that count? And didn't you follow up by referencing
this as "adding settings that change behaviour"? Does it change behavior or
not?

> Adding a configuration setting to make this a notice on some
installations and not on others, would just mean that anything that needs
to be able to run everywhere needs to take care to not rely on the setting
either way, making it harder to develop portable code.
What code now relies on this raising a warning rather than a notice that
can't consistently deal with it by using isset or the null coalescing
operator? Or are you subtly referring to the fact that this RFC is a
stepping stone to escalating the severity to throwing an error?
https://wiki.php.net/rfc/undefined_variable_error_promotion -> "This RFC
proposes that accessing an undefined variable is rendered illegal behaviour
in the next major version of PHP, and will result in an Error exception
being thrown if it occurs."

Here's another suggestion:
Make accesses to undefined array keys (objects, variables, etc) return a
new `undefined` primitive. That way, developers who are focused on writing
concise, readable code can continue to write and maintain code manageably,
and developers who are keen on writing a lot of code in a more "strict"
manner can handle undefined array key accesses consistently, without having
to rely on configuration settings.

> just fix your code.
Practically speaking, I'd much more likely stay on 7.4 or migrate to Node.


On Mon, Dec 12, 2022 at 5:52 PM Derick Rethans <derick@php.net> wrote:

> On 12 December 2022 22:20:27 GMT, Dan Liebner <dliebner@gmail.com> wrote:
>
> >It has been proposed to make the error level of "Undefined index"
> >configurable so that teams and individual developers can decide for
> >themselves how they want this situation to be handled. Given that:
> >
> >   - PHP has been treating this as an E_NOTICE for over 20 years
>
> But not in the last three years.
>
> >   - the change is a breaking change affecting many large codebases
> >   ubiquitously (unless one were to unadvisedly suppress E_WARNING errors)
>
> No, code doesn't break. It now shows a warning instead of an error. There
> is no behavioural change.
>
> >   - 7.4 is now deprecated
>
> Yes, as each release does 2+1 years. Which also means you've had 3 years
> to address this in your code base(s) already.
>
> >I think making the error level of "Undefined index" configurable is a very
> >reasonable suggestion, and I support it.
>
> Adding a configuration setting to make this a notice on some installations
> and not on others, would just mean that anything that needs to be able to
> run everywhere needs to take care to not rely on the setting either way,
> making it harder to develop portable code.
>
> We're also not generally anything near keen on adding settings that change
> behaviour , and suggesting to add one to make a warning a notice seems very
> far short of a bar that needs to be reached before many of us would agree
> to add a setting to make PHP less portable.
>
> Alternatively you can just fix your code.
>
> >Are we able to revisit this topic as a community and potentially bring in
> >more PHP developers from around the world to weigh in?
>
> You're always free to follow the RFC process, but I think you'll just up
> wasting your, and everybody else's, time with it.
>
> I can't see this being reversed, nor a setting added for, through an RFC
> process.
>
> cheers
> Derick
>
>

--000000000000da95d105efb51b1d--