First off, hello everyone, I'm Dan. I love PHP and I've been a PHP developer for over 20 years.
The recent change to elevating "Undefined index" from E_NOTICE to E_WARNING set forth and passed by https://wiki.php.net/rfc/engine_warnings to me seems antithetical to what PHP has been and what has made it a choice for developers over the last few decades. As the RFC points out, "Some languages, such as JavaScript, do not consider accesses to undefined array keys to be an error condition at all, and allow such an operation to be performed silently." For the last 20 years, it's been my impression that PHP also embraced this philosophy, and that raising an E_NOTICE for "Undefined index" was more or less offered as a debugging tool, as a matter of practicality. JavaScript returns the undefined primitive for accesses to undefined array and object keys. PHP returns the NULL primitive respectively despite raising an error. Here's my biggest criticism: the change essentially forces this: $arr['key'] to be rewritten as this (or some other intolerably bad alternative): isset($arr) && isset($arr['key']) && $arr['key'] This is a major regression in my opinion as far as productivity and readability are concerned. It has been proposed to make the error level of "Undefined index" configurable so that teams and individual developers can decide for themselves how they want this situation to be handled. Given that: - PHP has been treating this as an E_NOTICE for over 20 years - the change is a breaking change affecting many large codebases ubiquitously (unless one were to unadvisedly suppress E_WARNING errors) - 7.4 is now deprecated I think making the error level of "Undefined index" configurable is a very reasonable suggestion, and I support it. Are we able to revisit this topic as a community and potentially bring in more PHP developers from around the world to weigh in? Thank you, Dan
