Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114597
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\))
In-Reply-To: <CAGBsUrfZcOUJBeTGMHMN7XbU5421+RhRtEs41hgnT1mX-pm=4w@mail.gmail.com>
Date: Tue, 25 May 2021 19:13:26 +0200
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <9D54F5C4-CE4C-49E5-A00C-37AB66EE99C5@gmail.com>
References: <CAGBsUrfZcOUJBeTGMHMN7XbU5421+RhRtEs41hgnT1mX-pm=4w@mail.gmail.com>
To: Kamil Tekiela <tekiela246@gmail.com>
Subject: Re: [PHP-DEV] Disable autovivification on false
From: claude.pache@gmail.com (Claude Pache)


> Le 25 mai 2021 =C3=A0 18:23, Kamil Tekiela <tekiela246@gmail.com> a =
=C3=A9crit :
>=20
> Hi Internals,
>=20
> I'd like to start a discussion on the following RFC
> https://wiki.php.net/rfc/autovivification_false
> Particularly, I am looking for opinions on whether this behaviour =
should be
> left alone, should be disabled on false, or should be disabled on null =
and
> false, and left only for undefined variables.
>=20
> Autovivification is very useful in PHP, especially with =
multidimensional
> arrays and loops. However, the question is should we allow it on false =
and
> null values going forward.
>=20
> Kind Regards,
> Kamil Tekiela

Hi,

* IMO, null and undefined should be treated the same way, because for =
many purposes, they are not distinguished (e.g., isset() and ??). In =
general, I=E2=80=99m setting something to null when I want to avoid an =
=E2=80=9CUndefined symbol=E2=80=9D notice, I am sure it is not a bug, =
and I don=E2=80=99t want to scatter my code with `isset()` or `??` =
checks.

* In any case, the removing of the autovivification behaviour MUST be =
preceded by a period of deprecation notices.

=E2=80=94Claude=