Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114746
To: PHP internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] Disable autovivification on false
Thread-Index: AQHXUYJJrarjZ3CblUG+C59oTS0hoar0pdgAgADyGoCAEE0bgIAAAdb/
Date: Sat, 5 Jun 2021 22:13:43 +0000
Message-ID:
 <DM6PR07MB6618E4E8488AA4A66D5BA5B3F93A9@DM6PR07MB6618.namprd07.prod.outlook.com>
References:
 <CAGBsUrfZcOUJBeTGMHMN7XbU5421+RhRtEs41hgnT1mX-pm=4w@mail.gmail.com>
 <7DC82988-16E1-4228-BF94-46E633BD116E@woofle.net>
 <CAC5V6giWNBzaQf3XkGce2_1DOirjCsKK8TqwnxYGgE8JgyUBKw@mail.gmail.com>,<CAGBsUrdDP3tpSp8qc0hLVt5dNf8O-ODVHgVZh2Z2tqNGxprn6w@mail.gmail.com>
In-Reply-To:
 <CAGBsUrdDP3tpSp8qc0hLVt5dNf8O-ODVHgVZh2Z2tqNGxprn6w@mail.gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [KhOagOK+L+djbCqAWZAncOqW57qi9saJ8/k/t/j2l3csuAZd6/aFmUNFcpoKhFl1]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 1a9aaff4-aad8-4317-2198-08d9286f2ea1
x-ms-traffictypediagnostic: BN8NAM04HT036:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 cIgVyODLeoTPplGD72VGohIB033X+laTLVljqftDgMfqpdE0kET1scq+jJoz5f4fwcLR8RjP3Om979TIj7iJvdgdvXHL4vqtOulCCplRwWGCOT4j0d6xiupyeepYfRXTCUAVY5io9aPi8qX+QzNjY4s+iT4IOgtB/pJKBQ7mGQL9nMrBjI6cn5JnXqXjQHqIoWT0SoyZy8jvfjCnaGEJSf8ewOCVlPqmYkid4Mr0b4w8agqVNG4PCwpXgipnmGi/hU2hMniVAIPTyaBoJY+Q7qnFDMDfiVVDncFNOqa0nRULo8qmRr6EY17xMsq8S8OCNlIzeWMrtWxEkyd1UU90sZ6jz/FNVehhCB8lCyoDvwWurOpnXKifp9D0ee/H+ot4nPPedCd0Ez/YkP2CcsGGoHvfBZAXB2SvnthVv8xGFB5yM6+zO6z31pBkWN8b3IN6EEb+HBUi/2Knux+HmJmekg==
x-ms-exchange-antispam-messagedata:
 pVASimoaBthDPjl2wnXmEbvtLdBVSM2yBMSubT2Xt3X0wRMuTme8RJUca9/Pej3SebR1rqKdTQsmAuYWkg2ETvJhSm0xeNmxla7oHiATL17oanINFA1fvoWWtrXL7qi4yZpVit8VfDuEsN0BwqNpK6/8PWSDgO6ilVU03au2B/61QEKxphtsOENJQCoxrpjCg9lzjQcwHipDbOBWVWjLtQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: BN8NAM04FT039.eop-NAM04.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 1a9aaff4-aad8-4317-2198-08d9286f2ea1
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2021 22:13:43.7838
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8NAM04HT036
Subject: Re: [PHP-DEV] Disable autovivification on false
From: tysonandre775@hotmail.com (tyson andre)

Hi Kamil,=0A=
=0A=
> I have reworked the RFC based on some feedback. The improved RFC now will=
=0A=
> hold 2 votes. One vote to decide whether the behaviour should be deprecat=
ed=0A=
> from false, and another from null.=0A=
> =0A=
> If there are no objections then I would like to start the votes in a coup=
le=0A=
> of days.=0A=
> =0A=
> However, I would still like to hear from you whether you=0A=
> use autovivification from false and/or null in your projects. So far, I w=
as=0A=
> not able to identify when this would be useful in real-life scenarios.=0A=
> =0A=
> RFC: https://wiki.php.net/rfc/autovivification_false=0A=
=0A=
Without an implementation it'd be hard to actually tell what the impact wou=
ld be. There isn't one linked to from the RFC or on github.com/php/php-src.=
=0A=
You might have code in your application or external dependencies that relie=
s on that without you remembering or being aware of it for null.=0A=
=0A=
**I started working on a prototype independently just to get an idea of how=
 many things would encounter deprecations. See https://github.com/TysonAndr=
e/php-src/pull/17** (I am not one of the RFC's authors. If someone bases th=
eir implementation on that prototype PR please keep the authorship of initi=
al commits (e.g. `Co-Authored-By` in git)=0A=
=0A=
Also, what is the planned deprecation message, what about documenting all k=
inds of expressions that can cause autovivication, etc: e.g. `$x =3D &$fals=
eVar['offset']`=0A=
=0A=
=0A=
My assumption is that false would be reasonably practical to implement (thi=
s patch with `=3D=3D IS_FALSE` instead of `>=3D IS_NULL`, plus some changes=
 to the optimizer to account for the fact some dimension assignment stateme=
nts might now have.=0A=
For IS_NULL, that would probably require more familiarity with php's intern=
als than I have to be certain the implementation is correct and to properly=
 distinguish between undefined and null when automatically creating propert=
ies.=0A=
=0A=
Deprecation notices would be a lot more common for null than for false for =
example snippets such as the below, I see dozens of test failures in Zend/t=
ests with that prototype=0A=
=0A=
`$this->someArray[$offset] =3D $event` for the implicitly null `public $som=
eArray;`. https://github.com/vimeo/psalm/blob/105c6f3a1c6521e4077da39f05a94=
b1ddbd76249/src/Psalm/Internal/PhpVisitor/ReflectorVisitor.php#L399 is an e=
xample of that - the property's default is null, not the empty array.=0A=
- Obviously, that project would fix it quickly (I'm just testing on project=
s I've already downloaded), but the point is there may be a lot of code lik=
e that elsewhere.=0A=
=0A=
And code such as https://github.com/nikic/php-ast/blob/v1.0.12/util.php#L25=
 (for a PECL I use - that would be fixed very quickly for null if this pass=
ed, there may be a lot of code like that elsewhere and other projects may n=
ot be maintained)=0A=
=0A=
```=0A=
static $someVar; // equivalent to static $someVar =3D null;=0A=
if ($someVar !=3D=3D null) {=0A=
    return $someVar;=0A=
}=0A=
// ... someVar is still null=0A=
$someVar[] =3D '123';=0A=
```=0A=
=0A=
```=0A=
function example() {=0A=
    global $array;=0A=
    var_dump($array); // null, not undefined due to global $array convertin=
g undefined to null before creating a reference.=0A=
    $array[] =3D 1;=0A=
}=0A=
```=0A=
=0A=
----=0A=
=0A=
Overall, I'm in favor of this for false, but on the fence about null.=0A=
It seems like a lot of old and possibly unmaintained applications/libraries=
 might be converting null to arrays implicitly in ways such as the above,=
=0A=
and there wouldn't be too much of a benefit to users to forcing them to sta=
rt explicitly converting nulls to arrays before adding fields to arrays or =
taking references.=0A=
=0A=
If a project isn't already providing type information everywhere (and isn't=
 using a static analyzer such as phan/psalm) it may be easy to miss the pos=
sibility of a value being null in rare code paths,=0A=
but deprecating should give enough time to detect and fix typical issues be=
tween 8.1 and 9.0, and php 7.4's typed properties and 8.0's union types may=
 make type information much easier to track.=0A=
=0A=
I try to avoid autovivication from null in php projects I work on, but I'm =
not the only contributor to those=0A=
=0A=
Regards,=0A=
Tyson=