Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130075
Precedence: list
MIME-Version: 1.0
References: <CAOWwgp=JtbTSVCv9z=QGx9yS=8G72L-hcAjcOj33eEMLB0zfvg@mail.gmail.com>
 <CADyq6sJMXmDixLPO91P5d+5V28zhu0TVVfLxBKSUfF41JtYjkw@mail.gmail.com>
 <CAOWwgpnToAqGN=_bj9JB8gj-2PO9gqq2SgFYYg6LmPTSmCyQ=Q@mail.gmail.com>
 <4b74f9a1-96d2-4104-abdd-fe56c5e7016c@app.fastmail.com> <CAOWwgpnrnk-a6uczGnuE76rpd9mZvwXs=SHwuo+-4fWgLm9Jcg@mail.gmail.com>
 <585bfc82-a522-43ec-be42-b8945952fe8b@app.fastmail.com> <CAOWwgpn-agceHfEvRhyU0UEJCCif=6znH15=-m2B8ScEngUcEw@mail.gmail.com>
 <a5f91ba2-2fad-4e46-a4a7-a597972cf460@bastelstu.be> <CAOWwgpnr_GCxNL70ydiM_nqqn6RTNN8t_iX-O955dMc+ueGJYw@mail.gmail.com>
In-Reply-To: <CAOWwgpnr_GCxNL70ydiM_nqqn6RTNN8t_iX-O955dMc+ueGJYw@mail.gmail.com>
Date: Sun, 15 Feb 2026 19:20:06 +0100
Message-ID: <CAOWwgpk4eda1_8iM-Exnw74NzH+gUywpqv5Z551wPiPzz1cJQA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Allow Reassignment of Promoted Readonly
 Properties in Constructor
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f469af064ae0e3f1"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000f469af064ae0e3f1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Reposting as previous delivery apparently failed.

Le ven. 13 f=C3=A9vr. 2026, 15:52, Nicolas Grekas <nicolas.grekas+php@gmail=
.com>
a =C3=A9crit :

> Hi Tim,
>
> Le jeu. 5 f=C3=A9vr. 2026 =C3=A0 20:29, Tim D=C3=BCsterhus <tim@bastelstu=
.be> a =C3=A9crit :
>
>> Hi
>>
>> On 2/3/26 10:22, Nicolas Grekas wrote:
>> > The existing behavior is preserved: if a reassignment fails, it throws=
 a
>> > catchable Error. The implicit CPP assignment in a parent constructor
>> > happens before the parent body, so a child cannot "set first" and then
>> call
>> > ''parent::__construct()'' to avoid it; a try/catch in the parent canno=
t
>>
>> This is a good example that as far as I can tell is not explicitly
>> spelled out in the RFC: Please include an example where the *child* sets
>> a readonly property defined in the parent before calling the parent
>> constructor.
>>
>>      class P {
>>          public function __construct(
>>              public readonly string $x =3D 'P',
>>          ) { }
>>      }
>>
>>      class C extends P {
>>          public function __construct() {
>>              $this->x =3D 'C';
>>
>>              parent::__construct(); // Will this throw or not?
>>          }
>>      }
>>
>> More generally, as Rob, I stumbled upon the =E2=80=9CChild Classes Can R=
eassign
>> Parent Properties=E2=80=9D section, because it's least obviously correct
>> behavior to me.
>>
>> My understanding of this RFC is that it is intended to solve the case
>> where the class itself needs to perform some =E2=80=9Cpost-processing=E2=
=80=9D on a
>> promoted readonly property that it owns. Specifically, the property
>> becomes locked once the constructor completes.
>>
>> For the example in =E2=80=9CChild Classes Can Reassign Parent Properties=
=E2=80=9D my
>> mental model says that `$prop` is owned by `Parent_`, since `Parent_` is
>> the class that declared it. Thus it would be natural for me to =E2=80=9D=
lock=E2=80=9D
>> `$prop` once the `parent::__construct()` call completes. If the child
>> class needs to do special processing on the property, it has two options=
:
>>
>> 1. Not call the parent constructor. If the parent constructor logic is
>> unfit, then not calling the constructor is the right thing rather than
>> trying to revert part of what it did to a readonly property.
>>
>> 2. Call `parent::__construct()` with an appropriately modified value:
>> parent::__construct('child override');
>>
>> So to describe my expected semantics in more technical terms: The
>> implementation should =E2=80=9Cunlock=E2=80=9D the property after the =
=E2=80=9Cauto-generated
>> promotion logic=E2=80=9D finished and should =E2=80=9Crelock=E2=80=9D th=
e property when the
>> method with the auto-generated promotion logic finishes.
>>
>> In other words:
>>
>>      public function __construct(
>>          public readonly string $prop =3D 'parent default',
>>      ) {
>>          // Parent does NOT reassign here
>>      }
>>
>> should be equivalent to:
>>
>>      public function __construct(
>>          string $prop =3D 'parent default',
>>      ) {
>>          $this->prop =3D $prop;
>>          // unlock $this->prop (set IS_PROP_REINITABLE)
>>          try {
>>              // Parent does NOT reassign here
>>          } finally {
>>              // lock $this->prop (unset IS_PROP_REINITABLE)
>>          }
>>      }
>>
>> With this logic, the answer to initial =E2=80=9Cwill this throw=E2=80=9D=
 question of
>> this email would be =E2=80=9Cyes=E2=80=9D, because the implicit `$this->=
prop =3D $prop`
>> assignment happens before the unlock. I believe it would also more
>> closely match the semantics of `__clone()`.
>>
>>
> To be sure I understood you well: you are suggesting that mutability
> should be scoped to the constructor that declares the property (not any
> constructor on the object).
>
> This makes sense and I=E2=80=99ve implemented exactly that model:
> - Reassignment is allowed only while the declaring class constructor is
> active (including methods/closures called from it).
> - A child constructor can no longer reassign a parent-declared promoted
> readonly property.
> - =E2=80=9CChild sets first, then parent::__construct()=E2=80=9D now thro=
ws as expected.
> - The thrown Error is catchable from the child (around
> parent::__construct()), but not from inside the parent body before implic=
it
> CPP init.
> - Calling __construct() on an already-constructed object still cannot
> mutate readonly state.
>
> I also updated the RFC text and examples to state this explicitly, and
> added/updated tests for the inheritance/preemption scenarios.
>
> Anything else?
>
> Cheers,
> Nicolas
>

--000000000000f469af064ae0e3f1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Reposting as previous delivery apparently failed.</div><b=
r><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=
=3D"gmail_attr">Le ven. 13 f=C3=A9vr. 2026, 15:52, Nicolas Grekas &lt;<a hr=
ef=3D"mailto:nicolas.grekas%2Bphp@gmail.com">nicolas.grekas+php@gmail.com</=
a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div dir=3D"ltr">Hi Tim,</div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0jeu. 5 f=C3=A9vr. 2026 =C3=A0=C2=
=A020:29, Tim D=C3=BCsterhus &lt;<a href=3D"mailto:tim@bastelstu.be" target=
=3D"_blank" rel=3D"noreferrer">tim@bastelstu.be</a>&gt; a =C3=A9crit=C2=A0:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi<br>
<br>
On 2/3/26 10:22, Nicolas Grekas wrote:<br>
&gt; The existing behavior is preserved: if a reassignment fails, it throws=
 a<br>
&gt; catchable Error. The implicit CPP assignment in a parent constructor<b=
r>
&gt; happens before the parent body, so a child cannot &quot;set first&quot=
; and then call<br>
&gt; &#39;&#39;parent::__construct()&#39;&#39; to avoid it; a try/catch in =
the parent cannot<br>
<br>
This is a good example that as far as I can tell is not explicitly <br>
spelled out in the RFC: Please include an example where the *child* sets <b=
r>
a readonly property defined in the parent before calling the parent <br>
constructor.<br>
<br>
=C2=A0 =C2=A0 =C2=A0class P {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public function __construct(<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public readonly string $x =
=3D &#39;P&#39;,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0) { }<br>
=C2=A0 =C2=A0 =C2=A0}<br>
<br>
=C2=A0 =C2=A0 =C2=A0class C extends P {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public function __construct() {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0$this-&gt;x =3D &#39;C&#39;=
;<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0parent::__construct(); // W=
ill this throw or not?<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
=C2=A0 =C2=A0 =C2=A0}<br>
<br>
More generally, as Rob, I stumbled upon the =E2=80=9CChild Classes Can Reas=
sign <br>
Parent Properties=E2=80=9D section, because it&#39;s least obviously correc=
t <br>
behavior to me.<br>
<br>
My understanding of this RFC is that it is intended to solve the case <br>
where the class itself needs to perform some =E2=80=9Cpost-processing=E2=80=
=9D on a <br>
promoted readonly property that it owns. Specifically, the property <br>
becomes locked once the constructor completes.<br>
<br>
For the example in =E2=80=9CChild Classes Can Reassign Parent Properties=E2=
=80=9D my <br>
mental model says that `$prop` is owned by `Parent_`, since `Parent_` is <b=
r>
the class that declared it. Thus it would be natural for me to =E2=80=9Dloc=
k=E2=80=9D <br>
`$prop` once the `parent::__construct()` call completes. If the child <br>
class needs to do special processing on the property, it has two options:<b=
r>
<br>
1. Not call the parent constructor. If the parent constructor logic is <br>
unfit, then not calling the constructor is the right thing rather than <br>
trying to revert part of what it did to a readonly property.<br>
<br>
2. Call `parent::__construct()` with an appropriately modified value:<br>
parent::__construct(&#39;child override&#39;);<br>
<br>
So to describe my expected semantics in more technical terms: The <br>
implementation should =E2=80=9Cunlock=E2=80=9D the property after the =E2=
=80=9Cauto-generated <br>
promotion logic=E2=80=9D finished and should =E2=80=9Crelock=E2=80=9D the p=
roperty when the <br>
method with the auto-generated promotion logic finishes.<br>
<br>
In other words:<br>
<br>
=C2=A0 =C2=A0 =C2=A0public function __construct(<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public readonly string $prop =3D &#39;par=
ent default&#39;,<br>
=C2=A0 =C2=A0 =C2=A0) {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Parent does NOT reassign here<br>
=C2=A0 =C2=A0 =C2=A0}<br>
<br>
should be equivalent to:<br>
<br>
=C2=A0 =C2=A0 =C2=A0public function __construct(<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string $prop =3D &#39;parent default&#39;=
,<br>
=C2=A0 =C2=A0 =C2=A0) {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0$this-&gt;prop =3D $prop;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// unlock $this-&gt;prop (set IS_PROP_REI=
NITABLE)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0try {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Parent does NOT reassign=
 here<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} finally {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// lock $this-&gt;prop (uns=
et IS_PROP_REINITABLE)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
=C2=A0 =C2=A0 =C2=A0}<br>
<br>
With this logic, the answer to initial =E2=80=9Cwill this throw=E2=80=9D qu=
estion of <br>
this email would be =E2=80=9Cyes=E2=80=9D, because the implicit `$this-&gt;=
prop =3D $prop` <br>
assignment happens before the unlock. I believe it would also more <br>
closely match the semantics of `__clone()`.<br>
<br></blockquote><div><br></div><div class=3D"gmail_quote">To be sure I und=
erstood you well: you are suggesting that mutability should be scoped to th=
e constructor that declares the property (not any constructor on the object=
).</div><div class=3D"gmail_quote"><br></div>This makes sense and I=E2=80=
=99ve implemented exactly that model:<br>-=C2=A0Reassignment is allowed onl=
y while the declaring class constructor is active (including methods/closur=
es called from it).</div><div class=3D"gmail_quote">- A child constructor c=
an no longer reassign a parent-declared promoted readonly property.<br>- =
=E2=80=9CChild sets first, then parent::__construct()=E2=80=9D now throws a=
s expected.<br>- The thrown Error is catchable from the child (around paren=
t::__construct()), but not from inside the parent body before implicit CPP =
init.<br>- Calling __construct() on an already-constructed object still can=
not mutate readonly state.<br><br></div><div class=3D"gmail_quote">I also u=
pdated the RFC text and examples to state this explicitly, and added/update=
d tests for the inheritance/preemption scenarios.<br><br><div>Anything else=
?</div><div><br></div><div>Cheers,</div><div>Nicolas</div></div></div>
</blockquote></div>

--000000000000f469af064ae0e3f1--