Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117452
MIME-Version: 1.0
References: <9ecce8c9-c8bc-93e3-25f0-386c2c41ca1a@gmail.com> <92302377-6a49-d754-1210-b926c7381962@telia.com>
In-Reply-To: <92302377-6a49-d754-1210-b926c7381962@telia.com>
Date: Wed, 30 Mar 2022 14:34:04 +0200
Message-ID: <CAJmy8YG4O4JWy__eGf2z_RTUnheYibuT6d00+0CFKHkdaH5MiA@mail.gmail.com>
To: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= <bjorn.x.larsson@telia.com>
Cc: Rowan Tommins <rowan.collins@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ed37df05db6ec40b"
Subject: Re: [PHP-DEV] Re: Undefined variables and the array append operator
From: divinity76@gmail.com (Hans Henrik Bergan)

--000000000000ed37df05db6ec40b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> 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=C3=B6rn 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 +=3D 1 and $foo .=3D 'b=
lah'
> > raise "undefined variable" Warnings in PHP 8, and will throw Errors in
> > PHP 9. However, the very similar looking $foo[] =3D 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 the=
y
> > are defined as different Op Codes - ASSIGN_OP for .=3D and ASSIGN_DIM f=
or
> > []=3D, I believe. But that doesn't explain *why* ASSIGN_DIM behaves thi=
s
> 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[] =3D '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'] =3D 'bar', or $ref =3D&
> $foo[].
> >
> >
> > For example, consider the following simple validation code
> > [https://3v4l.org/pP5CU]:
> >
> > $requiredFields =3D ['name', 'age', 'hair_colour'];
> >
> > // Note: $errorString is not initialised
> > foreach ( $requiredFields as $field ) {
> >      if ( ! isset($_POST[$field]) ) {
> >          $errorString .=3D "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 $errorStrin=
g
> > 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[] =3D "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=C3=B6rn L
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--000000000000ed37df05db6ec40b--