Re: Revisiting RFC: Engine Warnings -- Undefined array index

From: Date: Tue, 13 Dec 2022 21:27:21 +0000
Subject: Re: Revisiting RFC: Engine Warnings -- Undefined array index
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-119139@lists.php.net to get a copy of this message
> Can you expand a bit on how you think distinguishing "undefined" from "null" would help? First off, I would be perfectly happy if undefined array/object index accesses went back to raising E_NOTICE. Undefined variables already resolve to NULL so in that sense NULL is already the "undefined" primitive. That said, if PHP were to introduce an undefined primitive, here's what I think would change: - NULL remains, and as such represents an "empty", yet defined, value. - Undefined variables and array/object accesses now resolve to "undefined" - $var = undefined is the equivalent of calling unset($var) - Biggest breaking change would probably be $undefinedVar === null is no longer true <?php // Here's how I think it would look in code null === undefined; // false null == undefined; // true isset($undy); // false $undy; // undefined, no error $undy === undefined; // true $arr = []; $arr['foo']; // undefined, no error $obj = (object)[]; $obj->prop; // undefined, no error $undy->method(); // fatal error function($param = undefined) {} // fatal error // more difficult scenarios... // JavaScript would throw an error // classic PHP behavior would resolve to null, therefore now undefined // either is arguably valid, latter would create need for optional chaining $undy['key']; // ? $undy->prop; // ?

« previous php.internals (#119139) next »