Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129897
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Fri, 23 Jan 2026 09:54:47 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <85e10caa-f577-4f8f-a93d-955348b67013@app.fastmail.com>
In-Reply-To: 
 <CAOWwgpms8JBKFpDjzRSYoWb=1_uOp6Ade91Xt7e8pyffCYG-hA@mail.gmail.com>
References: 
 <CAOWwgp=JtbTSVCv9z=QGx9yS=8G72L-hcAjcOj33eEMLB0zfvg@mail.gmail.com>
 <077e27345a1f5b7969c114684aede7e8@bastelstu.be>
 <CAOWwgpms8JBKFpDjzRSYoWb=1_uOp6Ade91Xt7e8pyffCYG-hA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Allow Reassignment of Promoted Readonly Properties in
 Constructor
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Jan 22, 2026, at 11:26 AM, Nicolas Grekas wrote:
> Thanks Tim, Larry,
>
> Le jeu. 22 janv. 2026 =C3=A0 17:21, Tim D=C3=BCsterhus <tim@bastelstu.=
be> a =C3=A9crit :
>> Hi
>>=20
>> 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
>>=20
>> Thank you. I have taken a look and have the following notes (for now):
>>=20
>> 1. In the Problem Statement: =E2=80=9COption 2: Use default parameter=20
>> expressions (limited):=E2=80=9D
>>=20
>> The example seems incorrect to me, particularly the =E2=80=9C// Canno=
t use $x in=20
>> default expression for $x=E2=80=9D comment doesn't make sense. Can yo=
u check you=20
>> pasted in the correct snippet?
>>=20
>> 2. Within the proposal: =E2=80=9CThe reassignment must occur directly=
 in the=20
>> constructor body of the declaring class (not via method calls, closur=
es,=20
>> or other indirect means)=E2=80=9D
>>=20
>> I believe this is inconsistent with `__clone()` where the readonly=20
>> property remains unlocked until the end of `__clone()` (and is then=20
>> locked).
>>=20
>> I'm seeing it is explained further below as =E2=80=9CThis restriction=
 exists=20
>> because the check verifies that the current executing function is the=20
>> constructor of the declaring class. When a method or closure executes=
,=20
>> the current function changes, even if it was called from the=20
>> constructor=E2=80=9D, which effectively means that you defined the se=
mantics=20
>> based on the implementation instead of the other way around, which I=20
>> consider problematic from a language design PoV. I'm positive it is=20
>> possible to find a better implementation here.
>>=20
>> 3. Within the =E2=80=9CRFC Impact=E2=80=9D section you removed the =E2=
=80=9CEcosystem=E2=80=9D=20
>> subsection from the template.
>>=20
>> I believe mentioning the ecosystem impact is relevant here. This chan=
ge=20
>> will likely require adjustments to static analysis tools and IDEs to =
not=20
>> point out the now-valid assignment as an error.
>>=20
>> 4. As per the updated RFC policy.
>>=20
>> Please already include the (closed) voting doodle in the RFC so there=
 is=20
>> no ambiguity here. Don't forget to include the =E2=80=9CAbstain=E2=80=
=9D option. My=20
>> suggested title would just be using the RFC title followed by a=20
>> questionmark :-)
>>=20
>> And please add a link to the list archives to the References section=20
>> (it's required per the policy and useful for future research). For yo=
ur=20
>> convenience, the correct link is this:=20
>> https://news-web.php.net/php.internals/129851
>>=20
>
>
> RFC text updated to account for your comments Tim, good catch and=20
> thanks for the help around RFC processes.
>
> About the assignment rule, Larry and you have the same reaction, so le=
t=20
> me take this as a good description of the most expected behavior by th=
e=20
> community ;-)
> I made the more restricted rule because I thought I should start with=20
> the stricter rule, and I get that would also be surprising somehow, so=20
> let's relax that.
>
> PR (and RFC) updated with the new logic, similar to __clone (and as=20
> boring as it can be ;P )
>
> Cheers,
> Nicolas

Boring is good in this case. :-)  I like the updates.  I only have two r=
emaining 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, th=
e RFC has been updated now such that updates outside of the constructor =
are allowed, provide the constructor is in the call stack.  Please remov=
e that clause, as it is incorrect.

And the LLM question, which warrants a separate discussion, I wager, and=
 is not an issue of the RFC text.

--Larry Garfield