Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117451
Message-ID: <92302377-6a49-d754-1210-b926c7381962@telia.com>
Date: Wed, 30 Mar 2022 12:17:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Content-Language: en-GB
To: Rowan Tommins <rowan.collins@gmail.com>
References: <9ecce8c9-c8bc-93e3-25f0-386c2c41ca1a@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Reply-To: =?UTF-8?Q?Bj=c3=b6rn_Larsson?= <bjorn.x.larsson@telia.com>
In-Reply-To: <9ecce8c9-c8bc-93e3-25f0-386c2c41ca1a@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: Undefined variables and the array append operator
From: internals@lists.php.net ("Björn Larsson via internals")

Den 2022-03-29 kl. 21:44, skrev Rowan Tommins:
> Hi all,
> 
> If $foo is not defined, statements such as $foo += 1 and $foo .= 'blah' 
> raise "undefined variable" Warnings in PHP 8, and will throw Errors in 
> PHP 9. However, the very similar looking $foo[] = 1 succeeds silently.
> 
> This seems odd to me, as "append to string" and "append to array" seem 
> like very similar operations, with most of the same use cases and 
> possible bugs.
> 
> 
>  From an *implementation* point of view, this is presumably because they 
> are defined as different Op Codes - ASSIGN_OP for .= and ASSIGN_DIM for 
> []=, I believe. But that doesn't explain *why* ASSIGN_DIM behaves this way.
> 
> A *historical* explanation might relate to Perl's "autovivification" 
> feature. However, PHP does *not* implement the same rules as Perl: for 
> instance, Perl will create array dimensions just by reading them, which 
> PHP does not; and Perl has a completely different type system, with 
> cases like "a scalar becomes a reference to a hash unless already a 
> reference to a list". Note also that I'm *not* talking about 
> multi-dimensional arrays with missing keys here, only undefined local 
> variables, as were the subject of the recent RFC.
> 
> The *observable behaviour* for most operators in PHP is the same:
> 
> 1) if the variable is undefined, consider the value to be null
> 2) coerce the value to the appropriate type; if the value is null, this 
> gives the relevant "empty" value, such as '', 0, or []
> 3) apply the operator
> 
> There isn't anything particularly special with $foo[] = 'bar' in this 
> case, except that it's the only operator that doesn't raise a Warning 
> (and planned Error) at step 1. The same goes for all the other uses of 
> the [] syntax I can think of, like $foo['key'] = 'bar', or $ref =& $foo[].
> 
> 
> For example, consider the following simple validation code 
> [https://3v4l.org/pP5CU]:
> 
> $requiredFields = ['name', 'age', 'hair_colour'];
> 
> // Note: $errorString is not initialised
> foreach ( $requiredFields as $field ) {
>      if ( ! isset($_POST[$field]) ) {
>          $errorString .= "Missing required field '$field'. ";
>      }
> }
> echo $errorString;
> 
> This gives an "Undefined variable" Notice / Warning / Error, depending 
> on the version. That's reasonable, as failing to initialise $errorString 
> might cause problems if this code is integrated into a loop or larger 
> function later.
> 
> However, switch the code from building up a string to building up an 
> array, and the result is identical, but the Notice / Warning / Error 
> goes away [https://3v4l.org/ojZ1O]:
> 
> // Note: $errorArray is not initialised
> foreach ( $requiredFields as $field ) {
>      if ( ! isset($_POST[$field]) ) {
>          $errorArray[] = "Missing required field '$field'. ";
>      }
> }
> echo implode('', $errorArray);
> 
> 
> Can anyone give a compelling reason why we should keep this 
> inconsistency, or should I raise an RFC to bring it in line with other 
> undefined variable accesses?
> 
> 
I think it deserves an RFC. Then we also capture your excellent 
explanation above!

Regards //Björn L