[RFC] Allow Reassignment of Promoted Readonly Properties in Constructor

> On Thu, 22 Jan 2026, Nicolas Grekas wrote: > > > Here is a new RFC for you to consider: > > https://wiki.php.net/rfc/promoted_readonly_constructor_reassign > > I read in the linked PR: > > "Team work with Claude Code opus 4.5 💪" > > This makes me instantly want to vote no to this. >

> Code LLMs have been trained on all kinds of open source (and perhaps > proprietary?) software. Open Source nearly always *atleast* has an > "Attribution Required" license. But, these "tools" do not follow these > licenses and the required. > > Therefore, there is no legally possible way to allow AI/LLM > contributions into the PHP source code. > > cheers, > Derick

> I read in the linked PR: > > "Team work with Claude Code opus 4.5 💪" > > This makes me instantly want to vote no to this.

> 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 > >

> > > Le 22 janv. 2026 à 16:33, Nicolas Grekas <nicolas.grekas+php@gmail.com> a > écrit : > > 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 > > > > Hi, > > I am reserved about the proposal, because this style of using CPP and > processing the value after the fact tends to favour brevity at the expense > of precision and clarity. Let’s illustrate that with two examples from the > RFC. First: > > ```php > class Config { > public function __construct( > public readonly ?string $cacheDir = null, > ) { > $this->cacheDir ??= sys_get_temp_dir() . '/app_cache'; > } > } > ``` > > As of today you can write: > > ```php > class Config { > public readonly string $cacheDir; > > public function __construct( > ?string $cacheDir = null, > ) { > $this->cacheDir = $cacheDir ??= sys_get_temp_dir() . '/app_cache'; > } > } > ``` > > Note that the property is marked as non-nullable, a precision that may be > useful for both programmers and static analysers. With your proposal, there > is no way to keep this information. > > > The second example is similar: > > ```php > class User { > public function __construct( > public readonly string $email, > ) { > if (!filter_var($email, FILTER_VALIDATE_EMAIL)) { > throw new InvalidArgumentException('Invalid email'); > } > $this->email = strtolower($email); // Normalize > } > } > ``` > > As of today, it can be written as: > > ```php > class User { > > /** @var non-empty-string & lowercase-string */ > public readonly string $email; > > public function __construct( > string $email, > ) { > if (!filter_var($email, FILTER_VALIDATE_EMAIL)) { > throw new InvalidArgumentException('Invalid email'); > } > $this->email = strtolower($email); // Normalize > } > } > ``` > > With your proposal, there is no obvious way to keep the additional > information provided in the phpdoc. Maybe we could imagine something like > that: > > ```php > class User { > /** > * @param string $email the e-mail address as provided > */ > public function __construct( > /** @var non-empty-string & lowercase-string the normalised e-mail > address */ > string $email, > ) { > if (!filter_var($email, FILTER_VALIDATE_EMAIL)) { > throw new InvalidArgumentException('Invalid email'); > } > $this->email = strtolower($email); // Normalize > } > } > ``` > > but it is obviously clearer (at least to my eyes) to keep the property and > the constructor parameter separate. > > One additional thought: Readonly properties carry a constraint that is > annoying at first, but that is finally beneficial for the clarity of code > that is written. When initialising such a property with something more > complex than what can be comfortably written in a single expression, I am > forced to write the intermediate results in a temporary variable and to > assign the final value to the property at the end of the process, instead > of transforming gradually the value of the property. The resulting code is > a few lines longer, but it is no less clear, even it is often clearer, > because it is obvious that this specific assignment supplies the final > value of the property, and there is no need to look further down to see > whether the value will undergo some additional transformations. As of > today, this “final assignment” may be part of the constructor signature; > with this RFC implemented, one can no longer know at a glance whether this > assignment is “final”. > > (Also I sympathise with Larry: rigid coding styles and static analysers’ > promoted “good practices” add problematic limitations that are not part of > the semantics of language. I prefer disabling checks in PHPStan rather than > downgrading to non-safe mutable properties and/or writing getters around > them.) > > >

> Hey Nicolas, > > > On Thu, 22 Jan 2026 at 16:34, Nicolas Grekas <nicolas.grekas+php@gmail.com> > wrote: > >> Dear all, >> >> Here is a new RFC for you to consider: >> https://wiki.php.net/rfc/promoted_readonly_constructor_reassign >> > > > What happens if one calls `$obj->__construct(1, 2, 3)` (on an already > instantiated `$obj`) in the context of this patch? >

>> 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. >> > > > Friendly reminder about this RFC. It's been quiet for 13 days so I plan to > start the vote on Thursday if there are no more concerns to the text of the > proposal. >