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
