On 27/01/2022 22:09, Larry Garfield wrote:
I am not sure what additional value is gained by making the scream even louder.
For us to make something an exception at engine level, is to stop
execution on the grounds that the engine no longer considers it safe to
continue.
That might be because a boolean was passed to a function that expects a
string, or in this case it might be because an undefined variable has
been read.
Notices / Warnings are irrelevant to this under the default
configuration, as in the absense of a userland error handler the engine
will happily allow code to continue executing even after a probably
undesirable state has been detected.
So what we're talking about here is changing the engine's definition of
what is safe to exclude read operations on an undefined variable.
I understand the argument that the behaviour is well defined, at least
for some operations, but I would posit that the vast majority of reads
on undefined variables are in fact unintentional side effects from
branching logic and are not the real intention at all.
If someone is insistent on working with nulls, there is an easy to use,
fully backwards compatible way to avoid these errors, which is to define
a variable as null prior to any branching logic.
For everyone else, we should offer this entirely sensible safety net.
What we don't want to do, I think, is end up in a situation like JS
where it has to be opted in: https://www.w3schools.com/js/js_strict.asp
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
