Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130095
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> <CAOWwgpmCMJxcqsyc7WXc90M1fvUhY6_3aa8P63bNJMPLR=ke0Q@mail.gmail.com>
 <3cd0d869-5a5b-467c-8eb4-3f8647ba7aa7@bastelstu.be>
In-Reply-To: <3cd0d869-5a5b-467c-8eb4-3f8647ba7aa7@bastelstu.be>
Date: Thu, 19 Feb 2026 10:49:27 +0100
Message-ID: <CAOWwgpm14su1A_pGFys29h0p+nzM6CLBWBYFSWLAjA2Gm93DNg@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>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fe652c064b2a382b"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000fe652c064b2a382b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Tim,

Le mer. 18 f=C3=A9vr. 2026 =C3=A0 22:29, Tim D=C3=BCsterhus <tim@bastelstu.=
be> a =C3=A9crit :

> Hi
>
> On 2/16/26 19:20, Nicolas Grekas wrote:
> > 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).
>
> Yes, because otherwise you might rely on implementation details of the
> parent constructor: Depending on whether the parent constructor
> reassigns internally, your reassignment in the child constructor either
> succeeds or fails.
>
> > 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 th=
rows as expected.
> > - The thrown Error is catchable from the child (around
> > parent::__construct()), but not from inside the parent body before
> implicit
> > 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.
>
> Thank you. I've checked the RFC and the explanation and semantics make
> sense to me. I've also reviewed (parts) of the tests and provided some
> feedback there. I'll take another look at the tests when you made the
> adjustments to make sure that everything in the RFC is properly tested
> to make sure we didn't miss and edge case.
>
> > Anything else?
>
> Yes, there is one edge case related to inheritance that isn't mentioned
> in the RFC and from what I see it's not tested either.
>
> Child classes can redefine readonly properties and they are then =E2=80=
=9Cowned=E2=80=9D
> by the child class. Thus we need to explain what happens in that case.
> I've prepared example for the three relevant cases I can think of. The
> follow from the existing semantics in a straight-forward fashion, but
> it's good to spell them out explicitly (and particularly test them).
>
> 1. Parent uses CPP, child redefines and reassigns.
>
>      class P1 {
>          public function __construct(
>              public readonly string $x =3D 'P',
>          ) { }
>      }
>
>      class C1 extends P1 {
>          public readonly string $x;
>
>          public function __construct() {
>              parent::__construct();
>
>              $this->x =3D 'C'; // This should fail.
>          }
>      }
>
> 2. Parent uses CPP and reassigns, child redefines.
>
>      class P2 {
>          public function __construct(
>              public readonly string $x =3D 'P1',
>          ) {
>              $this->x =3D 'P2'; // This should be legal.
>          }
>      }
>
>      class C2 extends P2 {
>          public readonly string $x;
>
>          public function __construct() {
>              parent::__construct();
>          }
>      }
>
> 3. Parent uses CPP, child uses CPP redefinition.
>
>      class P3 {
>          public function __construct(
>              public readonly string $x =3D 'P',
>          ) { }
>      }
>
>      class C3 extends P3 {
>          public function __construct(
>              public readonly string $x =3D 'C1',
>          ) {
>              parent::__construct(); // This should fail.
>          }
>      }
>
>

Thanks, I've added new test cases to cover this.
I've also improved tests as suggested on the PR.
And finally I updated the implementation to reuse IS_PROP_REINITABLE
instead of adding new flags + use an approach that doesn't require walking
the call stack.
PR and RFC updated accordingly, all green.

Nicolas

--000000000000fe652c064b2a382b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Tim,</div><br><div class=3D"gmail_quot=
e gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mer.=
 18 f=C3=A9vr. 2026 =C3=A0=C2=A022:29, Tim D=C3=BCsterhus &lt;<a href=3D"ma=
ilto:tim@bastelstu.be">tim@bastelstu.be</a>&gt; a =C3=A9crit=C2=A0:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">Hi<br>
<br>
On 2/16/26 19:20, Nicolas Grekas wrote:<br>
&gt; To be sure I understood you well: you are suggesting that mutability s=
hould<br>
&gt; be scoped to the constructor that declares the property (not any<br>
&gt; constructor on the object).<br>
<br>
Yes, because otherwise you might rely on implementation details of the <br>
parent constructor: Depending on whether the parent constructor <br>
reassigns internally, your reassignment in the child constructor either <br=
>
succeeds or fails.<br>
<br>
&gt; This makes sense and I=E2=80=99ve implemented exactly that model:<br>
&gt; - Reassignment is allowed only while the declaring class constructor i=
s<br>
&gt; active (including methods/closures called from it).<br>
&gt; - A child constructor can no longer reassign a parent-declared promote=
d<br>
&gt; readonly property.<br>
&gt; - =E2=80=9CChild sets first, then parent::__construct()=E2=80=9D now t=
hrows as expected.<br>
&gt; - The thrown Error is catchable from the child (around<br>
&gt; parent::__construct()), but not from inside the parent body before imp=
licit<br>
&gt; CPP init.<br>
&gt; - Calling __construct() on an already-constructed object still cannot<=
br>
&gt; mutate readonly state.<br>
&gt; <br>
&gt; I also updated the RFC text and examples to state this explicitly, and=
<br>
&gt; added/updated tests for the inheritance/preemption scenarios.<br>
<br>
Thank you. I&#39;ve checked the RFC and the explanation and semantics make =
<br>
sense to me. I&#39;ve also reviewed (parts) of the tests and provided some =
<br>
feedback there. I&#39;ll take another look at the tests when you made the <=
br>
adjustments to make sure that everything in the RFC is properly tested <br>
to make sure we didn&#39;t miss and edge case.<br>
<br>
&gt; Anything else?<br>
<br>
Yes, there is one edge case related to inheritance that isn&#39;t mentioned=
 <br>
in the RFC and from what I see it&#39;s not tested either.<br>
<br>
Child classes can redefine readonly properties and they are then =E2=80=9Co=
wned=E2=80=9D <br>
by the child class. Thus we need to explain what happens in that case. <br>
I&#39;ve prepared example for the three relevant cases I can think of. The =
<br>
follow from the existing semantics in a straight-forward fashion, but <br>
it&#39;s good to spell them out explicitly (and particularly test them).<br=
>
<br>
1. Parent uses CPP, child redefines and reassigns.<br>
<br>
=C2=A0 =C2=A0 =C2=A0class P1 {<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 C1 extends P1 {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public readonly string $x;<br>
<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=A0parent::__construct();<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0$this-&gt;x =3D &#39;C&#39;=
; // This should fail.<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
=C2=A0 =C2=A0 =C2=A0}<br>
<br>
2. Parent uses CPP and reassigns, child redefines.<br>
<br>
=C2=A0 =C2=A0 =C2=A0class P2 {<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;P1&#39;,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0) {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0$this-&gt;x =3D &#39;P2&#39=
;; // This should be legal.<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 C2 extends P2 {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public readonly string $x;<br>
<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=A0parent::__construct();<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
=C2=A0 =C2=A0 =C2=A0}<br>
<br>
3. Parent uses CPP, child uses CPP redefinition.<br>
<br>
=C2=A0 =C2=A0 =C2=A0class P3 {<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 C3 extends P3 {<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;C1&#39;,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0) {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0parent::__construct(); // T=
his should fail.<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
=C2=A0 =C2=A0 =C2=A0}<br>
<br></blockquote><div><br></div><div><br></div><div>Thanks, I&#39;ve added =
new test cases to cover this.</div><div>I&#39;ve also improved tests as sug=
gested on the PR.</div><div>And finally I updated the implementation to reu=
se IS_PROP_REINITABLE instead of adding new flags=C2=A0+ use an approach th=
at doesn&#39;t require walking the call stack.</div><div>PR and RFC updated=
 accordingly, all green.</div><div><br></div><div>Nicolas</div></div></div>

--000000000000fe652c064b2a382b--