Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129870
Precedence: list
MIME-Version: 1.0
References: <CAOWwgp=JtbTSVCv9z=QGx9yS=8G72L-hcAjcOj33eEMLB0zfvg@mail.gmail.com>
 <077e27345a1f5b7969c114684aede7e8@bastelstu.be>
In-Reply-To: <077e27345a1f5b7969c114684aede7e8@bastelstu.be>
Date: Thu, 22 Jan 2026 18:26:46 +0100
Message-ID: <CAOWwgpms8JBKFpDjzRSYoWb=1_uOp6Ade91Xt7e8pyffCYG-hA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Allow Reassignment of Promoted Readonly
 Properties in Constructor
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>, 
	Larry Garfield <larry@garfieldtech.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000628560648fd59a1"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--0000000000000628560648fd59a1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks Tim, Larry,

Le jeu. 22 janv. 2026 =C3=A0 17:21, Tim D=C3=BCsterhus <tim@bastelstu.be> a=
 =C3=A9crit :

> Hi
>
> 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
>
> Thank you. I have taken a look and have the following notes (for now):
>
> 1. In the Problem Statement: =E2=80=9COption 2: Use default parameter
> expressions (limited):=E2=80=9D
>
> The example seems incorrect to me, particularly the =E2=80=9C// Cannot us=
e $x in
> default expression for $x=E2=80=9D comment doesn't make sense. Can you ch=
eck you
> pasted in the correct snippet?
>
> 2. Within the proposal: =E2=80=9CThe reassignment must occur directly in =
the
> constructor body of the declaring class (not via method calls, closures,
> or other indirect means)=E2=80=9D
>
> I believe this is inconsistent with `__clone()` where the readonly
> property remains unlocked until the end of `__clone()` (and is then
> locked).
>
> I'm seeing it is explained further below as =E2=80=9CThis restriction exi=
sts
> because the check verifies that the current executing function is the
> constructor of the declaring class. When a method or closure executes,
> the current function changes, even if it was called from the
> constructor=E2=80=9D, which effectively means that you defined the semant=
ics
> based on the implementation instead of the other way around, which I
> consider problematic from a language design PoV. I'm positive it is
> possible to find a better implementation here.
>
> 3. Within the =E2=80=9CRFC Impact=E2=80=9D section you removed the =E2=80=
=9CEcosystem=E2=80=9D
> subsection from the template.
>
> I believe mentioning the ecosystem impact is relevant here. This change
> will likely require adjustments to static analysis tools and IDEs to not
> point out the now-valid assignment as an error.
>
> 4. As per the updated RFC policy.
>
> Please already include the (closed) voting doodle in the RFC so there is
> no ambiguity here. Don't forget to include the =E2=80=9CAbstain=E2=80=9D =
option. My
> suggested title would just be using the RFC title followed by a
> questionmark :-)
>
> And please add a link to the list archives to the References section
> (it's required per the policy and useful for future research). For your
> convenience, the correct link is this:
> https://news-web.php.net/php.internals/129851
>
>

RFC text updated to account for your comments Tim, good catch and thanks
for the help around RFC processes.

About the assignment rule, Larry and you have the same reaction, so let me
take this as a good description of the most expected behavior by the
community ;-)
I made the more restricted rule because I thought I should start with the
stricter rule, and I get that would also be surprising somehow, so let's
relax that.

PR (and RFC) updated with the new logic, similar to __clone (and as boring
as it can be ;P )

Cheers,
Nicolas

--0000000000000628560648fd59a1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Thanks Tim, Larry,</div><br><div class=3D=
"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">L=
e=C2=A0jeu. 22 janv. 2026 =C3=A0=C2=A017:21, Tim D=C3=BCsterhus &lt;<a href=
=3D"mailto:tim@bastelstu.be">tim@bastelstu.be</a>&gt; a =C3=A9crit=C2=A0:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi<br>
<br>
Am 2026-01-22 16:33, schrieb Nicolas Grekas:<br>
&gt; Here is a new RFC for you to consider:<br>
&gt; <a href=3D"https://wiki.php.net/rfc/promoted_readonly_constructor_reas=
sign" rel=3D"noreferrer" target=3D"_blank">https://wiki.php.net/rfc/promote=
d_readonly_constructor_reassign</a><br>
<br>
Thank you. I have taken a look and have the following notes (for now):<br>
<br>
1. In the Problem Statement: =E2=80=9COption 2: Use default parameter <br>
expressions (limited):=E2=80=9D<br>
<br>
The example seems incorrect to me, particularly the =E2=80=9C// Cannot use =
$x in <br>
default expression for $x=E2=80=9D comment doesn&#39;t make sense. Can you =
check you <br>
pasted in the correct snippet?<br>
<br>
2. Within the proposal: =E2=80=9CThe reassignment must occur directly in th=
e <br>
constructor body of the declaring class (not via method calls, closures, <b=
r>
or other indirect means)=E2=80=9D<br>
<br>
I believe this is inconsistent with `__clone()` where the readonly <br>
property remains unlocked until the end of `__clone()` (and is then <br>
locked).<br>
<br>
I&#39;m seeing it is explained further below as =E2=80=9CThis restriction e=
xists <br>
because the check verifies that the current executing function is the <br>
constructor of the declaring class. When a method or closure executes, <br>
the current function changes, even if it was called from the <br>
constructor=E2=80=9D, which effectively means that you defined the semantic=
s <br>
based on the implementation instead of the other way around, which I <br>
consider problematic from a language design PoV. I&#39;m positive it is <br=
>
possible to find a better implementation here.<br>
<br>
3. Within the =E2=80=9CRFC Impact=E2=80=9D section you removed the =E2=80=
=9CEcosystem=E2=80=9D <br>
subsection from the template.<br>
<br>
I believe mentioning the ecosystem impact is relevant here. This change <br=
>
will likely require adjustments to static analysis tools and IDEs to not <b=
r>
point out the now-valid assignment as an error.<br>
<br>
4. As per the updated RFC policy.<br>
<br>
Please already include the (closed) voting doodle in the RFC so there is <b=
r>
no ambiguity here. Don&#39;t forget to include the =E2=80=9CAbstain=E2=80=
=9D option. My <br>
suggested title would just be using the RFC title followed by a <br>
questionmark :-)<br>
<br>
And please add a link to the list archives to the References section <br>
(it&#39;s required per the policy and useful for future research). For your=
 <br>
convenience, the correct link is this: <br>
<a href=3D"https://news-web.php.net/php.internals/129851" rel=3D"noreferrer=
" target=3D"_blank">https://news-web.php.net/php.internals/129851</a><br><b=
r></blockquote><div><br></div><div><br></div><div>RFC text updated to accou=
nt for your comments Tim, good catch and thanks for the help around RFC pro=
cesses.</div><div><br></div><div>About the assignment=C2=A0rule, Larry and =
you have the same reaction, so let me take this as a good description of th=
e most expected behavior by the community ;-)</div><div>I made the more res=
tricted rule because I thought I should start with the stricter rule, and I=
 get that would also be surprising somehow, so let&#39;s relax that.</div><=
div><br></div><div>PR (and RFC) updated with the new logic, similar to __cl=
one (and as boring as it can be ;P )</div><div><br></div><div>Cheers,</div>=
<div>Nicolas</div></div></div>

--0000000000000628560648fd59a1--