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

Hi Larry, Le dim. 25 janv. 2026 à 19:53, Larry Garfield <larry@garfieldtech.com> a écrit : > On Sat, Jan 24, 2026, at 12:09 PM, Nicolas Grekas wrote: > > >> Boring is good in this case. :-) I like the updates. I only have two > remaining quibbles. > >> > >> > All other readonly semantics remain unchanged (no modification > outside constructor, no unsetting, etc.) > >> > >> As previously stated, "no modification outside constructor" is not, and > has never been, part of the language semantics of readonly. In fact, the > RFC has been updated now such that updates outside of the constructor are > allowed, provide the constructor is in the call stack. Please remove that > clause, as it is incorrect. > > > > How would you phrase this? > > To me, point 3 above makes this clear: "The reassignment must occur > > while a constructor of the object is on the call stack (methods and > > closures called from the constructor are allowed)" > > Then, point 7: "All other readonly semantics remain unchanged (no > > modification outside constructor, no unsetting, etc.)" has enough > > context to me to be clear. > > > > No? > > There's a very subtle caveat here. Readonly properties that are not yet > initialized can be set from anywhere, not just the constructor. That is > the language semantic, regardless of what the PHPStan/Psalm authors think.. > :-) > > In this particular case, because the property is being set in the > constructor preamble, essentially, it cannot then be re-assigned... EXCEPT > in the constructor due to this RFC. But that's a subtle, easy to miss > caveat. Hence why I'd prefer wording that doesn't imply (to those that > don't catch that subtlety) that the language doesn't allow readonly to be > assigned outside of the constructor. > > This is a particular pet peeve of mine because I have very good use cases > for assigning to a readonly property outside of the constructor, but always > therefore have to disable that check in PHPStan as a result. Hence why I > harp on it so much. :-) I updated the text to make this more clear, thanks for the suggestion!