Re: [RFC] Readonly Property Defaults

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