Hi Kamil, > I have reworked the RFC based on some feedback. The improved RFC now will > hold 2 votes. One vote to decide whether the behaviour should be deprecated > from false, and another from null. > > If there are no objections then I would like to start the votes in a couple > of days. > > However, I would still like to hear from you whether you > use autovivification from false and/or null in your projects. So far, I was > not able to identify when this would be useful in real-life scenarios. > > RFC: https://wiki.php.net/rfc/autovivification_false
Without an implementation it'd be hard to actually tell what the impact would be. There isn't one linked to from the RFC or on github.com/php/php-src. You might have code in your application or external dependencies that relies on that without you remembering or being aware of it for null. **I started working on a prototype independently just to get an idea of how many things would encounter deprecations. See https://github.com/TysonAndre/php-src/pull/17** (I am not one of the RFC's authors. If someone bases their implementation on that prototype PR please keep the authorship of initial commits (e.g. `Co-Authored-By` in git) Also, what is the planned deprecation message, what about documenting all kinds of expressions that can cause autovivication, etc: e.g. `$x = &$falseVar['offset']` My assumption is that false would be reasonably practical to implement (this patch with `== IS_FALSE` instead of `>= IS_NULL`, plus some changes to the optimizer to account for the fact some dimension assignment statements might now have. For IS_NULL, that would probably require more familiarity with php's internals than I have to be certain the implementation is correct and to properly distinguish between undefined and null when automatically creating properties. 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/tests with that prototype `$this->someArray[$offset] = $event` for the implicitly null `public $someArray;`. https://github.com/vimeo/psalm/blob/105c6f3a1c6521e4077da39f05a94b1ddbd76249/src/Psalm/Internal/PhpVisitor/ReflectorVisitor.php#L399 is an example of that - the property's default is null, not the empty array. - Obviously, that project would fix it quickly (I'm just testing on projects I've already downloaded), but the point is there may be a lot of code like that elsewhere. 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 passed, there may be a lot of code like that elsewhere and other projects may not be maintained) ``` static $someVar; // equivalent to static $someVar = null; if ($someVar !== null) { return $someVar; } // ... someVar is still null $someVar[] = '123'; ``` ``` function example() { global $array; var_dump($array); // null, not undefined due to global $array converting undefined to null before creating a reference. $array[] = 1; } ``` ---- Overall, I'm in favor of this for false, but on the fence about null. 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, and there wouldn't be too much of a benefit to users to forcing them to start explicitly converting nulls to arrays before adding fields to arrays or taking references. 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 possibility of a value being null in rare code paths, but deprecating should give enough time to detect and fix typical issues between 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. I try to avoid autovivication from null in php projects I work on, but I'm not the only contributor to those Regards, Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
