> 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; // ?
