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

Hello everyone,

I’m opening this discussion to gather opinions and support regarding a change introduced in PHP 8 and later versions: the stricter handling of undefined array keys.

For years, accessing an undefined array key would result in a Notice. While technically not an ideal practice, it was a very common pattern used by countless developers, often for checking the existence of a key and simultaneously using its value if present, or assigning a default if not.

Since PHP 8, accessing an undefined array key now throws a Warning (or even an Error in some contexts, depending on the setup and how the code interacts with error handling). While I understand the rationale behind this change—promoting stricter code and preventing potential bugs—my experience, and that of many developers I’ve spoken with, suggests that the old behavior, despite its “imperfection,” was often more practical, concise, and elegant for everyday coding.

I’ve had numerous conversations with developers across various projects and skill levels, and a recurring theme is that many find the forced isset() or null coalescing operator (??) in every single instance to be verbose and, frankly, less readable in scenarios where the old Notice was perfectly acceptable and manageable. This often leads to code that is more cluttered without necessarily adding significant value in terms of bug prevention for well-understood use cases.

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.

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: PHP: rfc:engine_warnings

Discussion threads (that I could find in a quick search):

* Revisiting RFC: Engine Warnings -- Undefined array index - Externals (revisit discussion)
* [VOTE] Reclassifying engine warnings - Externals (vote)
* [RFC] Reclassifying engine warnings - Externals (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: PHP: rfc:howto

(Note that it's entirely possible I've missed one or more relevant RFCs. See PHP: rfc - I often find it helpful to use Googles `site:PHP: 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)