Le ven. 23 janv. 2026 à 16:59, Larry Garfield <[email protected]> a écrit :
> 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 <[email protected]> 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. > 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?
