Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129860
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Thu, 22 Jan 2026 10:11:24 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <2ecdd74b-c86c-402d-b7ff-d20acb5cbe56@app.fastmail.com>
In-Reply-To: 
 <CAOWwgp=JtbTSVCv9z=QGx9yS=8G72L-hcAjcOj33eEMLB0zfvg@mail.gmail.com>
References: 
 <CAOWwgp=JtbTSVCv9z=QGx9yS=8G72L-hcAjcOj33eEMLB0zfvg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Allow Reassignment of Promoted Readonly Properties in
 Constructor
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Jan 22, 2026, at 9:33 AM, Nicolas Grekas wrote:
> 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

I can see the benefit of this, though I do have some concerns.

> The reassignment must occur directly in the constructor body of the declaring class (not via method calls, closures, or other indirect means)

This could be an issue.  I understand the argument for it, but for objects designed to be both constructed directly and deserialized the constructor may not always be called.  A common solution is to move the shared logic out to a private method, say validate(), and then call validate() from both __construct() and __unserialize() (or the equivalent for a particular serializer).  That would no longer be possible with this limitation, thus requiring duplication of code.

> Child classes cannot reassign parent's promoted readonly properties

Why?  

> All other readonly semantics remain unchanged (no modification outside constructor, no unsetting, etc.)

The "no modification outside constructor" *is not part of the language semantics*.  It is a recommended practice invented by SA tools.  

I also share Derick's disdain for code produced by Grand Theft Autocomplete, and the legal risks therein.

--Larry Garfield