Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129921
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Sun, 25 Jan 2026 12:50:13 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <1776f008-f444-4952-8f98-3a2693801145@app.fastmail.com>
In-Reply-To: 
 <CAOWwgpnJ1Fjv+ATioxkCd2vuvDtZVsAeDoVqjson5Ae+-FwVxg@mail.gmail.com>
References: 
 <CAOWwgp=JtbTSVCv9z=QGx9yS=8G72L-hcAjcOj33eEMLB0zfvg@mail.gmail.com>
 <077e27345a1f5b7969c114684aede7e8@bastelstu.be>
 <CAOWwgpms8JBKFpDjzRSYoWb=1_uOp6Ade91Xt7e8pyffCYG-hA@mail.gmail.com>
 <85e10caa-f577-4f8f-a93d-955348b67013@app.fastmail.com>
 <CAOWwgpnJ1Fjv+ATioxkCd2vuvDtZVsAeDoVqjson5Ae+-FwVxg@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 Sat, Jan 24, 2026, at 12:09 PM, Nicolas Grekas wrote:

>> 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?

There's a very subtle caveat here.  Readonly properties that are not yet initialized can be set from anywhere, not just the constructor.  That is the language semantic, regardless of what the PHPStan/Psalm authors think. :-)

In this particular case, because the property is being set in the constructor preamble, essentially, it cannot then be re-assigned... EXCEPT in the constructor due to this RFC.  But that's a subtle, easy to miss caveat.  Hence why I'd prefer wording that doesn't imply (to those that don't catch that subtlety) that the language doesn't allow readonly to be assigned outside of the constructor.

This is a particular pet peeve of mine because I have very good use cases for assigning to a readonly property outside of the constructor, but always therefore have to disable that check in PHPStan as a result.  Hence why I harp on it so much. :-)

--Larry Garfield