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

On Thu, Jan 22, 2026, at 11:26 AM, Nicolas Grekas wrote: > Thanks Tim, Larry, > > Le jeu. 22 janv. 2026 à 17:21, Tim Düsterhus <tim@bastelstu.be> a écrit : >> Hi >> >> Am 2026-01-22 16:33, schrieb Nicolas Grekas: >> > Here is a new RFC for you to consider: >> > >> > https://wiki.php.net/rfc/promoted_readonly_constructor_reassign >> >> Thank you. I have taken a look and have the following notes (for now): >> >> 1. In the Problem Statement: “Option 2: Use default parameter >> expressions (limited):” >> >> The example seems incorrect to me, particularly the “// Cannot use $x in >> default expression for $x” comment doesn't make sense. Can you check you >> pasted in the correct snippet? >> >> 2. Within the proposal: “The reassignment must occur directly in the >> constructor body of the declaring class (not via method calls, closures, >> or other indirect means)” >> >> I believe this is inconsistent with __clone() where the >> readonly >> property remains unlocked until the end of __clone() (and >> is then >> locked). >> >> I'm seeing it is explained further below as “This restriction exists >> because the check verifies that the current executing function is the >> constructor of the declaring class. When a method or closure executes, >> the current function changes, even if it was called from the >> constructor”, which effectively means that you defined the semantics >> based on the implementation instead of the other way around, which I >> consider problematic from a language design PoV. I'm positive it is >> possible to find a better implementation here. >> >> 3. Within the “RFC Impact” section you removed the “Ecosystem” >> subsection from the template. >> >> I believe mentioning the ecosystem impact is relevant here. This change >> will likely require adjustments to static analysis tools and IDEs to not >> point out the now-valid assignment as an error. >> >> 4. As per the updated RFC policy. >> >> Please already include the (closed) voting doodle in the RFC so there is >> no ambiguity here. Don't forget to include the “Abstain” option. My >> suggested title would just be using the RFC title followed by a >> questionmark :-) >> >> And please add a link to the list archives to the References section >> (it's required per the policy and useful for future research). For your >> convenience, the correct link is this: >> https://news-web.php.net/php.internals/129851 >> > > > RFC text updated to account for your comments Tim, good catch and > thanks for the help around RFC processes. > > About the assignment rule, Larry and you have the same reaction, so let > me take this as a good description of the most expected behavior by the > community ;-) > I made the more restricted rule because I thought I should start with > the stricter rule, and I get that would also be surprising somehow, so > let's relax that. > > PR (and RFC) updated with the new logic, similar to __clone (and as > boring as it can be ;P ) > > Cheers, > Nicolas 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. And the LLM question, which warrants a separate discussion, I wager, and is not an issue of the RFC text. --Larry Garfield