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. - Have a longer timeline: fix the unset() behaviour in 9.0, and the initializer in 10.0. But that just postpones both the pain and the gain. - Actually require all properties to have a type at some point in the future, so the behaviour of untyped properties becomes a moot point. I'm pretty sure this is a non-starter since we didn't even manage to remove "var" in favour of "public", but I wanted to say it for completeness. Maybe someone can come up with some other variation or compromise? Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
