Re: [RFC] Allow Reassignment of Promoted Readonly Properties in Constructor

On Thu, Jan 22, 2026, at 9:33 AM, Nicolas Grekas wrote: > Dear all, > > Here is a new RFC for you to consider: > https://wiki.php.net/rfc/promoted_readonly_constructor_reassign > > As a quick intro, my motivation for that RFC is that I find it quite > annoying that readonly properties play badly with CPP (constructor > property promotion). > > Doing simple processing of any argument before assigning it to a > readonly property forces opting out of CPP. > > This RFC would allow setting once a readonly property in the body of a > constructor after the property was previously (and implicitly) set > using CPP. > > This allows keeping property declarations in their compact form while > still enabling validation, normalization, or conditional initialization. > > Cheers, > Nicolas I can see the benefit of this, though I do have some concerns. > The reassignment must occur directly in the constructor body of the declaring class (not via > method calls, closures, or other indirect means) This could be an issue. I understand the argument for it, but for objects designed to be both constructed directly and deserialized the constructor may not always be called. A common solution is to move the shared logic out to a private method, say validate(), and then call validate() from both __construct() and __unserialize() (or the equivalent for a particular serializer). That would no longer be possible with this limitation, thus requiring duplication of code. > Child classes cannot reassign parent's promoted readonly properties Why? > All other readonly semantics remain unchanged (no modification outside constructor, no > unsetting, etc.) The "no modification outside constructor" *is not part of the language semantics*. It is a recommended practice invented by SA tools. I also share Derick's disdain for code produced by Grand Theft Autocomplete, and the legal risks therein. --Larry Garfield