Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129835
Precedence: list
MIME-Version: 1.0
References: <CAJS5taANCzu9W+mzEd0-nE0hh22Jbb170jK7n2yBHjh7yj-gdA@mail.gmail.com>
 <dcee998d-4727-46a2-ba3c-03e71863ef3e@bastelstu.be>
In-Reply-To: <dcee998d-4727-46a2-ba3c-03e71863ef3e@bastelstu.be>
Date: Thu, 22 Jan 2026 00:33:06 +0100
Message-ID: <CAPyj-LBLqUu=_wYRSdmmk2vDtoQcuJNQ-K4y0yns_hj_t9_KWg@mail.gmail.com>
Subject: Re: [PHP-DEV] [php-src] PR #20903: GH-10497 (const obj->prop write) -
 language change notes
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Tim

On Sun, Jan 18, 2026 at 1:28=E2=80=AFPM Tim D=C3=BCsterhus <tim@bastelstu.b=
e> wrote:
>
> On 1/15/26 07:36, Khaled Alam wrote:
> >     A potentially surprising case: some newly-valid writes can be a no-=
op
> >     when they target a temporary const value, e.g.
> >     - const X =3D [1,2,3];  X[] =3D 4;
> >        - const Y =3D ['a' =3D> 1];  Y['b'] =3D 2;
> >
> > These become valid syntax but have no effect because the write happens =
on a
> > temporary basis.
> >
> > Feedback on semantics + expected behavior for the temporary-write case =
is
> > appreciated.
>
> This is too unexpected / error-prone for me. Trying to write into arrays
> should remain disallowed / an Error, since this is never (?) useful.

No strong opinions on my part, but I'd like to point out that similar
situations already exist.

https://3v4l.org/ARMMS#v8.4.14

    const C =3D [1, 2, 3];
    function foo(): array {
        return C;
    }
    foo()[] =3D 4;
    var_dump(C);

PHP will happily duplicate the array returned from foo() to append 4,
without warning. The original array in C remains unmodified. It might
make sense for ASSIGN_DIM to warn/throw if OP1 is not a "pointer"
(indirect, reference or object), as then the operation will never have
an effect. But it seems to me this is a distinct issue.

Ilija