Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117341
MIME-Version: 1.0
References: <4724184.31r3eYUQgx@come-prox15amd> <37421f61-4e2e-53d3-56d0-022a3c21ed2e@gmx.de>
 <4f8bad56-267a-9279-1e57-66fd10b8874f@gmail.com> <CAESVnVrKfUNTqo8W8MLc4gUPsXtYTpSbmV53VTZQ67J-r6bOTA@mail.gmail.com>
 <6230f8bf.1c69fb81.b1e54.162dSMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <6230f8bf.1c69fb81.b1e54.162dSMTPIN_ADDED_MISSING@mx.google.com>
Date: Wed, 16 Mar 2022 00:02:28 +0100
Message-ID: <CACwt+JchibthDT4NgMdh4HHhf_F1hNbpNf6xFnGF-kXsSLHGDA@mail.gmail.com>
To: Mark Randall <marandall@php.net>
Cc: PHP Development <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002b4bca05da49cb0f"
Subject: Re: [PHP-DEV] [VOTE] Undefined Variable Error Promotion
From: patrickallaert@php.net (Patrick ALLAERT)

--0000000000002b4bca05da49cb0f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Mark and the list,

Le mar. 15 mars 2022 =C3=A0 21:36, Mark Randall <marandall@php.net> a =C3=
=A9crit :

> Who knows, maybe PHP 9 can be the version that removes remove *all*
> warnings from the zend engine.
>

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.

While it may not be a good practice. It's not that we cannot recover from
that, it is more that we don't want to. This doesn't match really the
notion of "error" which is not very much documented, apart from
https://www.php.net/manual/en/errorfunc.constants.php:

"E_ERROR: Fatal run-time errors. These indicate errors that can not be
recovered from, such as a memory allocation problem. Execution of the
script is halted."

Currently E_WARNING is documented as:
"Run-time warnings (non-fatal errors). Execution of the script is not
halted."

This describes how the core reacts, not when it is supposed to happen.

This could potentially be extended to:
"Run-time warnings (non-fatal errors) that are likely to denote bad
programming practice (like the use of something undefined) that are usually
solved with code changes. Execution of the script is not halted."

But then this wouldn't be true anymore if this RFC passes as it would
result in:
Undefined variables: Error
Undefined index: Warning
Undefined property: Warning

IMHO, this leads to something more inconsistent than what we have now.

I know other RFCs could target the other aspects. But there is no way to
vote "yes, provided that all other RFCs under the same umbrella would pass
for the same version".
This is probably a limitation of our current RFC process, but in order to
maintain as much consistency as possible, I see no other option than voting
"no" even though I am +1 on the principle.

Kind regards,
Patrick

--0000000000002b4bca05da49cb0f--