On 09/07/2025 13:39, Salvatore Forino wrote:
It feels like a change pushed by a few for the many, without a broader
consensus from the PHP development community. Given that PHP is a
language used by millions globally, I believe such a fundamental shift
in how we interact with arrays should ideally reflect the preferences
of a wider majority.
Therefore, I propose we open a democratic discussion and potentially a
vote on this matter.
Like the vast majority of changes to the language, these changes were
discussed and voted on via the internals mailing list.
The behavior described was part of the engine warnings RFC:
https://wiki.php.net/rfc/engine_warnings
Discussion threads (that I could find in a quick search):
* https://externals.io/message/119109 (revisit discussion)
* https://externals.io/message/106940 (vote)
* https://externals.io/message/106713 (rfc discussion)
You can further search the internals archives on https://externals.io
(among other mirrors / archives) - there are likely other related
discussions on this that may not have come up in my searches
You should also read up on the RFC process: https://wiki.php.net/rfc/howto
(Note that it's entirely possible I've missed one or more relevant RFCs.
See https://wiki.php.net/rfc - I often find it helpful to use Googles
`site:https://wiki.php.net/rfc` feature when searching for RFCs where
I'm not sure exactly what I'm looking for)
Anyone can subscribe and post to the internals mailing list - it's not
limited to existing established contributors. You're likely to get far
more response posting there as not all internals contributors regularly
read this list.
I do recommend reading the previous discussions on this topic before
posting there as it'll give you a good idea of the arguments you're
likely to come up against, allowing you to prepare counter points to
them where appropriate.
The PHP language has no official commercial backing and heavily relies
on contributors who come and go over time. This also means it's often
not worthless revisiting discussions as opinions of the voting
contributors can change over time.
---
As a long-time PHP developer who maintains long-standing codebases my
personal opinion is that these changes are good. Undefined variables, or
unexpected null values when undefined values only result in a notice or
warning, are a common cause of bugs that cause corrupted / malformed
data that can have further unexpected impact on an application in my
experience.
The mitigations are easy and while they may require a little more
typing, make the code more concise - making it clearer when code expects
values to possibly not exist and subsequently (should be) designed to
handle null values.
Static analysis tools like PHPStan can be very helpful in catching cases
developers may miss before they hit production, and the mitigations
further help these tools in their analysis of code.
The "strict vs loose" debate is a long standing one which will surely
continue for many many years to come (probably as long as PHP is in
active use). I personally think the language developers are striking a
good balance between allowing code that's strict enough to avoid
unintentional bugs, while still allowing developers to write relatively
"quick and dirty" scripts when they wish to (I also do plenty of this,
regularly using PHP for shell scripts or quick web-based utilities)
