Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130170
Precedence: list
MIME-Version: 1.0
Date: Wed, 25 Feb 2026 15:41:09 +0100
Message-ID: <CAPyj-LB-ShZMswSFBjF4dHgn9xf4CJJsHODu7R-bgxq3WgphDw@mail.gmail.com>
Subject: [PHP-DEV] Re: [RFC] Readonly Variables
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Joshua

On Mon, 23 Feb 2026 21:29:19 +0000, josh@wcflabs.de wrote:

 > https://wiki.php.net/rfc/readonly-variables

First of all, thank you for your proposal and the effort you've put into
the implementation.

I'm skeptical about the usefulness of local immutability as a whole. I
personally don't recognize local mutability as a significant source of
bugs, contrary to action at a distance. Putting that aside:

I understand your implementation is a proof-of-concept, but the approach
looks wrong to me. I think if local immutability is added, it should
mostly be a compile-time concept. The implementation currently add a new
opcode for readonly assignment, and touches all existing assignments to
add immutability checks. This seems mostly unnecessary with few
exceptions (those being var-vars, globals, extract, pass-by-reference
reference promotion, etc.), as the compiler can assert that the variable
being assigned to isn't marked as readonly. The implementation shows an
instruction count increase of 5.2%, 1.3% and 2.1% for Zend/bench.php,
Symfony Demo and Wordpress, respectively. That should mostly go away
with a compile time approach.

There are likely also some limitations to the compile-time approach:

- Without runtime tracking of readonly (and the concept of block
scoping) every variable name could only be declared once in a function.
- Disallowing `$readonly['foo'] = 'bar';` at compile-time will
incorrectly restrict ArrayOffset, which I personally find acceptable.
- Similar to the above, compile-time checks are insufficient for future
value types. [1] `$readonly->foo = 'bar';` should fail if $readonly is a
value type, which will necessarily require additional runtime checks.
This is further complicated by `$readonly->foo->bar = 'baz';`, which
should fail _only_ if $readonly->foo itself is also a value type. Given
this issue applies to arbitrarily long chains, I don't know how this
could be solved.

For the reasons mentioned, I don't think I'd support this RFC in any
form. Nonetheless, I appreciate the care that has gone both into the RFC
and implementation.

Ilija

[1] https://wiki.php.net/rfc/structs-v2