Dear internals,
It's now time to open the vote for the following RFC:
https://wiki.php.net/rfc/promoted_readonly_constructor_reassign
The vote will close on 2026-04-07 at 16:00 UTC.
Cheers,
Nicolas
Hi Nicolas
On Mon, Mar 23, 2026 at 4:39 PM Nicolas Grekas
nicolas.grekas+php@gmail.com wrote:
It's now time to open the vote for the following RFC:
https://wiki.php.net/rfc/promoted_readonly_constructor_reassignThe vote will close on 2026-04-07 at 16:00 UTC.
I voted "no" because I think the property logic, especially readonly,
is already too convoluted. We've already had to deploy multiple fixes
to make it workable (those being unlocking during __clone, and clone()
with). In my opinion, if you need to modify a property during
construction, there's already private(set), for which local mutability
is easy to restrict.
Nonetheless, thanks for the RFC and thanks for entertaining my ideas
for the technical changes.
Ilija
Hi,
I also voted “no”, for essentially the same reason as Ilija.
To me, this is the wrong use case for readonly. If a property is expected
to change during construction, then initializing it as readonly and later
reassigning it feels like it weakens the semantics instead of clarifying
them.
One of the main values of readonly is that it communicates a very simple
rule: once initialized, the property does not change. Introducing
exceptions around constructor promotion makes that model harder to reason
about, while the language already has alternatives for cases where
controlled local mutability is needed.
So while I understand the motivation behind the RFC, I think this moves
readonly further toward special-case behavior, when it would be better to
keep it strict and predictable.
Kind regards,
Michał Marcin Brzuchalski
pon., 23 mar 2026 o 16:40 Nicolas Grekas nicolas.grekas+php@gmail.com
napisał(a):
Dear internals,
It's now time to open the vote for the following RFC:
https://wiki.php.net/rfc/promoted_readonly_constructor_reassignThe vote will close on 2026-04-07 at 16:00 UTC.
Cheers,
Nicolas
So while I understand the motivation behind the RFC, I think this moves
readonly further toward special-case behavior, when it would be better to
keep it strict and predictable.
I agree with Ilija and Michal here. I can see why this might seem useful, but the detailed rules feel very complicated, weakening the value of "readonly".
I think it also weakens the premise of CPP, which was to merge three pieces of code: the property declaration, the parameter declaration, and the assignment.
Perhaps what's actually needed is a variant that only merges the assignment with the property declaration? That would then cover the case mentioned in the RFC with a change in type, as well as the "readonly" case:
class Config {
public function __construct(
?string $cacheDir = null,
) {
public readonly string $this->cacheDir = $cacheDir ?? `sys_get_temp_dir()` . '/app_cache';
}
}
I'm not sure I love it, but it feels more consistent with the intention of both CPP and readonly.
Regards,
Rowan Tommins
[IMSoP]
Hi all,
It's now time to open the vote for the following RFC:
https://wiki.php.net/rfc/promoted_readonly_constructor_reassign
The vote will close on 2026-04-07 at 16:00 UTC
The vote is now closed.
The RFC has declined with 11 in favor and 10 not in favor.
Thanks for your attention on this proposal!
Nicolas