Inherited Readonly Properties: Visibility Widening Decision in PHP 8.2

Short answer

The premise needs a correction: PHP 8.2 already permits widening the visibility of an inherited readonly property. A child class may redeclare a parent's private readonly or protected readonly property as protected or public, and the engine accepts it. What is forbidden is the opposite direction — narrowing visibility — and dropping the readonly modifier on redeclaration. So there is no pending decision blocking you; the uncertainty in the RFC discussion concerned edge refinements, not the basic widening case.

Why widening is allowed

PHP's property variance rule has always been covariant on visibility: a child may expose more, never less. Readonly adds a write-once constraint, and widening visibility does not weaken that constraint — the property can still only be initialized once, from a scope where initialization is legal, and cannot be modified or unset afterward. Because widening does not break the immutability guarantee, the engine treats it as compatible. This is consistent across PHP 8.1 (readonly properties) and 8.2 (readonly classes, where every declared instance property is implicitly readonly).

What remains illegal

• Narrowing visibility (e.g., public readonly to protected) — fatal error, same as any property.
• Redeclaring without readonly — the flag must be preserved.
• A non-readonly class extending a readonly class.
• Static readonly properties — a compile error regardless of visibility.

The real trap: redeclaration resets initialization

When a child redeclares the property, it becomes a new declaration. If the parent's constructor initialized it but the child's construction path skips that initialization, reads will throw an "uninitialized property" Error. Verify the write-once guarantee still holds after widening with a minimal script on your exact runtime:

php -v
# then run: parent declares protected readonly, child redeclares public,
# initialize once, attempt a second write — expect an Error.

Recommendation for library authors

Declare readonly properties at the widest visibility you are comfortable committing to, and prefer protected over private if subclasses legitimately need to initialize them — initialization of a private property is restricted to the declaring class's scope. This guidance reflects 8.1/8.2 semantics; later versions may refine readonly interactions (e.g., with property hooks), so pin behavior with a test on your target version rather than assuming forward stability.