On Fri, Nov 17, 2023, at 10:47 AM, Rowan Tommins wrote: > On 16 November 2023 21:38:48 GMT, Jakub Zelenka <bu...@php.net> wrote: >>This sounds like a huge BC break. Probably bigger and a bit harder to fix >>than disallowing dynamic props. > > More common, maybe; but trivial to fix: add "=null" at the end of all > untyped property declarations that don't already have an initializer. > It would be trivial to automate with something like Rector. > > >>Maybe it would be better to do this as some sort of opt in behaviour > > We already have the opt-in behaviour: add "mixed" to a property > declaration, and it no longer gets initialized to null. The aim of the > RFC is to eliminate that distinction, not to encourage typed properties. > > > > I do however agree that the initial value part is quite disruptive, and > am open to suggestions on how to minimise that. A couple that have > occurred to me: > > - Change the unset() behaviour, which we're already planning to make > produce errors in 9.0; but keep the implicit initializer. In other > words, make "public $foo;" equivalent to "public mixed $foo=null;" The > obvious downside is that it's just as weird a special-case for users to > learn as what we have now.
This seems like the easiest way forward, with the fewest breaks. In particular, I would therefore expect reflection to treat `public $foo` as though it had been `public mixed $foo = null`, and thus normalize how the object looks. That's one less edge case for me to deal with, so I support that. As noted, though, there's still readonly to consider. Of note, both ?? and ??= currently treat uninitialized the same as null; this is a very good feature that is extraordinarily useful, and has the nice side effect of reducing the impact of this change. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
