Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130154
Content-Type: text/plain;
	charset=utf-8
Precedence: list
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.300.41.1.7\))
Subject: Re: [PHP-DEV] [RFC] Readonly Variables
In-Reply-To: <CAGBsUrdczien7yCvQLNMQXOcJnZbmjOgAMQi4rD8uRxzkVsm8Q@mail.gmail.com>
Date: Tue, 24 Feb 2026 19:52:11 +0100
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <7FA75C32-BC65-487B-BE44-272FEED42F04@wcflabs.de>
References: <CE12E852-00AA-41E1-8E8A-B82B89F801A4@wcflabs.de>
 <CAGBsUrdczien7yCvQLNMQXOcJnZbmjOgAMQi4rD8uRxzkVsm8Q@mail.gmail.com>
To: Kamil Tekiela <tekiela246@gmail.com>
From: josh@wcflabs.de (=?utf-8?Q?Joshua_R=C3=BCsweg?=)

Hello Kamil,=20

> On 23. Feb 2026, at 22:58, Kamil Tekiela <tekiela246@gmail.com> wrote:
>=20
> 1. Why the use of readonly keyword? Why not const or some new keyword,
> e.g. locked.

I spent a long time thinking about the right keyword. In an early stage =
of development I chose `const`, as it is already used in this way in =
JavaScript, for example. However, the further I developed the feature =
and the more feedback I gathered from others, the more I gravitated =
towards `readonly`. The `readonly` keyword is already used in PHP for =
class properties and serves exactly the same purpose: declaring =
variables as immutable. Reusing `readonly` for variables is therefore =
consistent with existing PHP semantics. The `const` keyword, on the =
other hand, has fundamentally different semantics in PHP. A `const` =
declaration at the top level defines a globally accessible constant, and =
inside a class it defines a class constant. This is quite different from =
a locally scoped immutable variable, and using const for this feature =
would likely cause confusion for PHP developers who are already familiar =
with its existing meaning. Introducing an entirely new keyword for this =
purpose, such as `locked`, would in my opinion be counterproductive, as =
it could be unintuitive for developers who are already familiar with =
`readonly` and its meaning in PHP.

> 2. Why does unset not remove the variable completely? If you want a
> feature to only unlock the variable then it probably needs a new
> keyword, e.g. unlock

Thank you for pointing that out, as I apparently expressed myself =
ambiguously in the RFC. `unset()` behaves exactly as it does for regular =
variables: it removes the variable entirely. The only additional effect =
is that the `readonly` flag is cleared along with it, meaning the =
variable name can subsequently be reused with a new assignment, without =
the `readonly` flag. I have updated the RFC to make this behavior more =
explicit.

Regarding the idea of a dedicated unlock mechanism: I don't think this =
is necessary, and I honestly don't see a practical use case for it. If a =
variable needs to be modified after its initial assignment, it simply =
should not be declared as readonly in the first place.

> 3. What exactly does this mean: "Readonly variables inside loops are
> permitted but limited to a single declaration"? What does a single
> declaration look like?

A readonly variable declared inside a loop is exposed to the outer =
scope, just like any other variable in PHP. This means that on the =
second iteration, PHP would attempt to re-assign an already initialized =
readonly variable, which results in a fatal error. A "single =
declaration" therefore means that the readonly variable can only be =
initialized once throughout the entire execution of the loop, not once =
per iteration.

I hope this clarifies the behavior. Please let me know if you have any =
further questions.

> 4. How will this impact optimizer and JIT?

Thank you for raising this point. I have not yet investigated the impact =
on the optimizer and JIT, as the current implementation is an initial =
proof of concept intended to gather feedback from the community. I will =
definitely look into this before the voting phase and investigate =
whether and how readonly variables can be leveraged for potential =
optimizations. I will report back with my findings.

> 5. You said that readonly variables cannot be used with the global
> keyword. But what about readonly variables in global scope? Will they
> still behave like a typical global variable?

I am not entirely sure what you mean by "typical global variable =
behavior", so I will try to address what I believe you are asking.
If your question is whether a readonly variable declared in the global =
scope can be imported into a function via the `global` statement, the =
answer is no. Importing a readonly variable via `global` is forbidden =
and results in an error.
If you are asking whether readonly variables declared in the global =
scope are automatically accessible in function scopes, the answer is =
also no. Readonly variables follow the same scoping rules as regular =
variables, meaning they are not automatically available inside =
functions, just as regular variables are not.
If you meant something else entirely, please feel free to clarify and I =
will be happy to address it.

> 6. What exactly counts as a variable declaration? When is it a valid
> syntax to use this keyword? I don't think PHP had the concept of
> variable declaration until now.

By "declaration" I simply mean a regular variable assignment prefixed =
with the readonly keyword:

```
<?php
readonly $foo =3D "bar=E2=80=9D;
```

You are right that PHP has not had a formal concept of variable =
declaration until now. The readonly keyword in this context is purely a =
modifier on a standard assignment statement, signaling that the variable =
cannot be re-assigned after its initial value has been set. Any valid =
assignment expression can be used as the initial value, including object =
instantiation, function calls, or scalar values.

> 7. What about compound variables such as arrays and objects?

The behavior differs depending on the type of value assigned to a =
readonly variable.

For arrays, the entire array is immutable. This means that neither the =
array itself nor its elements can be modified after the initial =
assignment:

```
<?php
readonly $arr =3D [1, 2, 3];
$arr[] =3D 4; // Error: Cannot re-assign readonly variable
$arr[0] =3D 99; // Error: Cannot re-assign readonly variable
```

For objects, the behavior is consistent with how readonly works for =
class properties: the variable binding is immutable, meaning the object =
reference cannot be replaced with a different object. However, the =
internal state of the object itself can still be modified:

```
<?php
readonly $obj =3D new stdClass();
$obj->value =3D "changed"; // Valid: modifying the object's internal =
state is allowed
$obj =3D new stdClass(); // Error: Cannot re-assign readonly variable
```

I have added examples for both cases to the RFC to make this behavior =
explicit.

> I would prefer starting with readonly parameters as I feel that would
> bring the most value.

I find the idea of readonly parameters interesting and have already =
given it some thought. However, it is out of scope for this RFC, as I =
wanted to keep the initial proposal focused and manageable. I have =
already mentioned it in the Future Scope section of the RFC as a =
potential natural extension that could be addressed in a separate RFC in =
the future.

> I think it would also be worthwhile to investigate a simpler syntax
> for define().

It is worth noting that PHP already provides two ways to define global =
constants: `define()` and the `const` keyword. Both serve a different =
purpose than readonly variables, as they are globally accessible and not =
scoped to a local or functional context. See: https://3v4l.org/1r6gk

Cheers,=20
Joshua R=C3=BCsweg