Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117114
To: internals@lists.php.net
Date: Tue, 22 Feb 2022 11:32:48 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.6.1
References: <620eda0f.1c69fb81.d2cb1.0846SMTPIN_ADDED_MISSING@mx.google.com>
 <5efecaef-a024-3c61-e12e-ffc342956718@gmail.com>
Content-Language: en-GB
In-Reply-To: <5efecaef-a024-3c61-e12e-ffc342956718@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
From: marandall@php.net (Mark Randall)
Message-ID: <php.internals-117114@news.php.net>

On 18/02/2022 11:23, Rowan Tommins wrote:
> - undefined array keys
> - undefined object properties
> - array access on a non-array
> - property access on a non-object


I'd encourage those to be discussed, but they are unrelated to this RFC.

I think most of them would pass fairly easily, but undefined array keys 
is out the outlier and has a reasonable chance of being rejected at this 
time. However, with their being 4 years before the launch of 9.0 (and 
the next opportunity to change it) opinion may change between now and then.

I've updated the RFC to define accessing a variable as attempting to 
read its value for use in an expression without accounting for the 
possibility of it being unset.

I have also included the warning message to narrow this down further, 
and noted that things which account for undefined variables such as 
isset, empty and null coalesce will remain unaffected.

If there's am existing formal definition someone wishes to contribute, 
I'd be happy to update it.

One thing maybe worth mentioning is that while most operators such as 
++, +=, .= etc will be covered by this change, $undefined[] = 1; will 
not be.

Mark Randall