> RFC. There are other inconsistencies as well now, depending on how the undefined variable comes to exist
absolutely, but shouldn't try to do too much in a single rfc, wouldn't want it to be rejected for the wrong reasons ^^ On Wed, 30 Mar 2022 at 12:17, Björn Larsson via internals < internals@lists.php.net> wrote: > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
