Re: Proposal: Reconsideration of PHP's Undefined Array Key Behavior (Pre-PHP 8 Syntax)

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)