(sorry for the double post; for some reason Thunderbird messed up
formatting on web in the last attempt)
Hey Larry,
On 11.07.26 06:02, Larry Garfield wrote:
> On Sat, Jul 4, 2026, at 5:03 AM, Nick Sdot wrote:
>> Hey Internals,
>>
>> I would like to present a tiny, five-line-removal RFC allowing default
>> values on readonly properties.
>>
>> Allowing default values on readonly class properties enables creating a
>> strict contract for implementation property values that will not change
>> at runtime -- as in, constant-like behaviour with contract. I would love
>> doing that.
>>
>> Please find the RFC text here:
>> https://wiki.php.net/rfc/readonly_property_defaults
> I had been planning to say "meh, doesn't seem like it would hurt
anything," but as Tim pointed out with unserialize, it potentially could
hurt something. That makes me skeptical.
>
> I also want to call out, as the RFC notes, that this is already a
solved problem with private(set). It's not quite the same as readonly,
but for most practical purposes it's close enough and already addresses
the use case this RFC.
Thanks for the feedback.
I have to push back. It is not a solved problem. In fact, `private(set)`
is *not* only "not quite the same". Both features solve fundamentally
different problems -- `private(set)` has a foot gun `readonly` does not
have.
Because this point comes up repeatedly here is a concrete example:
```
final class PipelineOne // private(set)
{
public private(set) array $orderedPipelineSteps = [
\Thing\StepDoSomethingTwo::class,
\Thing\StepAtReportBeginning::class,
\Thing\StepDoSomethingOne::class,
];
public function describe(): array
{
\sort($this->orderedPipelineSteps); // whoopsie, should have
copied first
$ordered = $this->orderedPipelineSteps;
// do stuff
return $ordered;
}
}
final readonly class PipelineTwo // readonly
{
public function __construct(
public array $orderedPipelineSteps = [
\Thing\StepDoSomethingTwo::class,
\Thing\StepAtReportBeginning::class,
\Thing\StepDoSomethingOne::class,
],
) {}
public function describe(): array
{
\sort($this->orderedPipelineSteps); // whoopsie, should have
copied first
$ordered = $this->orderedPipelineSteps;
// do stuff
return $ordered;
}
}
// ###################### private(set) ######################
$one = new PipelineOne();
\var_dump($one->describe());
// array(3) {
// [0]=>
// string(27) "Thing\StepAtReportBeginning" // good, now ordered
// [1]=>
// string(24) "Thing\StepDoSomethingOne"
// [2]=>
// string(24) "Thing\StepDoSomethingTwo"
//}
\var_dump($one->orderedPipelineSteps);
// array(3) {
// [0]=>
// string(27) "Thing\StepAtReportBeginning" // whoopsie, this should
NOT be first!
// [1]=>
// string(24) "Thing\StepDoSomethingOne"
// [2]=>
// string(24) "Thing\StepDoSomethingTwo"
//}
// ###################### readonly ######################
$two = new PipelineTwo();
\var_dump($two->describe());
//Fatal error: Uncaught Error: Cannot indirectly modify readonly
property PipelineTwo::$orderedPipelineSteps
```
With `private(set)` accidental mutation is legal. With `readonly`,
modification after initialisation is illegal. Both are great and useful
features, but `private(set)` only controls visibility not mutation. As
the above example proves, `readonly` is strict when it comes to mutation
and would have prevented the bug while `private(set)` happily ignores it
because mutation happens from within the class. With `readonly` it would
have been surfaced that I did:
```
\sort($this->orderedPipelineSteps); // whoopsie, mutated
$ordered = $this->orderedPipelineSteps;
```
instead of:
```
$ordered = $this->orderedPipelineSteps;
\sort($ordered);
```
This alone is reason enough to use `readonly` over `private(set)`; less
verbosity is a cherry on top.
Note: only to make the example copy & work without the PR branch I used
constructor property promotion here. With the RFC, `PipelineTwo` can
declare the property default directly, without allowing outside
modification.
--
Cheers
Nick
