[PHP-DEV] [VOTE] Allow Reassignment of Promoted Readonly Properties in Constructor

Mailing Lists php.internals
1

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

2

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:
PHP: rfc:promoted_readonly_constructor_reassign

The 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

3

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_reassign

The vote will close on 2026-04-07 at 16:00 UTC.

Cheers,
Nicolas

4

On 24 March 2026 14:06:53 GMT, "Michał Marcin Brzuchalski" <michal.brzuchalski@gmail.com> wrote:

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]