Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130022
Message-ID: <a5f91ba2-2fad-4e46-a4a7-a597972cf460@bastelstu.be>
Date: Thu, 5 Feb 2026 20:29:12 +0100
Precedence: list
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Allow Reassignment of Promoted Readonly
 Properties in Constructor
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>,
 Rob Landers <rob@bottled.codes>
Cc: PHP Internals List <internals@lists.php.net>
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>
Content-Language: en-US
In-Reply-To: <CAOWwgpn-agceHfEvRhyU0UEJCCif=6znH15=-m2B8ScEngUcEw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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 cannot

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 = 'P',
         ) { }
     }

     class C extends P {
         public function __construct() {
             $this->x = 'C';

             parent::__construct(); // Will this throw or not?
         }
     }

More generally, as Rob, I stumbled upon the “Child Classes Can Reassign 
Parent Properties” 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 “post-processing” on a 
promoted readonly property that it owns. Specifically, the property 
becomes locked once the constructor completes.

For the example in “Child Classes Can Reassign Parent Properties” 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 ”lock” 
`$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 “unlock” the property after the “auto-generated 
promotion logic” finished and should “relock” the property when the 
method with the auto-generated promotion logic finishes.

In other words:

     public function __construct(
         public readonly string $prop = 'parent default',
     ) {
         // Parent does NOT reassign here
     }

should be equivalent to:

     public function __construct(
         string $prop = 'parent default',
     ) {
         $this->prop = $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 “will this throw” question of 
this email would be “yes”, because the implicit `$this->prop = $prop` 
assignment happens before the unlock. I believe it would also more 
closely match the semantics of `__clone()`.

Best regards
Tim Düsterhus