Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130161
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: <20260224004547.C3CD51A00BD@lists.php.net>
Date: Tue, 24 Feb 2026 21:15:01 +0100
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <EAF71BB0-CB2D-4C02-A74D-0B3CB627592C@wcflabs.de>
References: <CE12E852-00AA-41E1-8E8A-B82B89F801A4@wcflabs.de>
 <CAGBsUrdczien7yCvQLNMQXOcJnZbmjOgAMQi4rD8uRxzkVsm8Q@mail.gmail.com>
 <20260224004547.C3CD51A00BD@lists.php.net>
To: Ben Ramsey <ramsey@php.net>
From: josh@wcflabs.de (=?utf-8?Q?Joshua_R=C3=BCsweg?=)

Hi Ben,=20

> On 24. Feb 2026, at 01:45, Ben Ramsey <ramsey@php.net> wrote:
>=20
> According to this RFC, both of these would be forbidden:
>=20
>   readonly $a =3D new Foo();
>   $b =3D $a;

As Tim already clarified, there is a common misconception about how PHP =
handles objects internally. In PHP, objects are not passed by reference =
in the sense of the `&` operator, but via an object identifier. This =
means that `$b =3D $a` simply copies the object identifier, not a =
reference to the variable itself, and is therefore perfectly valid:

```
<?php
readonly $a =3D new Foo();
$b =3D $a;
```

The readonly flag only prevents re-assignment of `$a` itself. The `&` =
operator, on the other hand, would create a true reference to the =
variable `$a`, which would allow `$a` to be modified indirectly through =
`$b`, effectively circumventing the readonly flag. This is why taking a =
reference of a readonly variable is forbidden.
I hope this clears up the concern.

> and:
>=20
>   function modify(Foo $value): void {}
>   readonly $a =3D new Foo();
>   modify($a);
>=20
> I said "according to this RFC," but the RFC doesn't mention object =
behavior with readonly at all, which I think might be an oversight. The =
only place it hints at allowing objects is in the examples with `new =
PDO()`.
>=20
> Is the idea to allow objects (and arrays) similar to how JavaScript =
handles these with `const`? That is, the objects and arrays themselves =
are mutable, but the variable name cannot be reassigned to a new object =
or array?

Regarding your question about object and array behavior: you are correct =
that the RFC did not explicitly document this, which was indeed an =
oversight on my part.
As already mentioned above, the variable binding is immutable, meaning =
`$a` cannot be reassigned to a different object, but the internal state =
of the object can still be modified. This is also consistent with how =
the readonly attribute behaves for class properties:

```
<?php
readonly $a =3D new Foo();
$a->value =3D "foo"; // Valid: modifying the object's internal state is =
allowed
$a =3D new Foo(); // Error: Cannot re-assign readonly variable
```

For arrays, however, the behavior differs from JavaScript. In PHP, =
arrays are value types with copy-on-write semantics, not reference =
types. This means that a readonly array is fully immutable, as 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
```

I have added explicit examples for both objects and arrays to the RFC to =
make this behavior clear. I appreciate you flagging this.

(I apologize for the duplicate email, Ben. The first attempt was sent =
from an incorrect address and did not go through properly.)=20

Cheers,
Joshua R=C3=BCsweg=