Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:131068
Precedence: list
MIME-Version: 1.0
Date: Fri, 29 May 2026 22:10:57 +0200
Message-ID: <CAOWwgpmPoigvKi0PAUKRB4XUsAM0jC09LC_xsRjoYEoMYBXVew@mail.gmail.com>
Subject: [PHP-DEV] Proposed fix ??/empty and __isset materialization of properties
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000139e6e0652fa7279"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000139e6e0652fa7279
Content-Type: text/plain; charset="UTF-8"

Dear internals,

Following the discussion around the __exists() RFC, PR #22181 [1] isolates
the engine-only piece that was suggested there. The broader __exists()
proposal remains on the table separately; this PR is scoped to just the
sequencing issue.

When `??` or `empty()` triggers `__isset()` on a magic property
and `__isset()` writes into the property table (a pattern used in
userland to lazily initialise a property), the engine currently calls
`__get()` afterwards anyway. That redundant `__get()` is mostly cosmetic,
but it can trip up patterns where `__get()` routes through a parent
that doesn't know about the just-materialised property.

The patch adds a property-table re-check after `__isset()` returns true: if
the property now exists physically, the value is returned directly and
`__get()` is skipped. `isset()` itself is unchanged (it
has never called `__get()`).

This sits between bug-fix and feature, so per the usual process: planning
to merge to master in two weeks unless there are objections.

The PR has already been reviewed by @iluuu1994 and @arnaud-lb.

[1] https://github.com/php/php-src/pull/22181
[2] https://github.com/php/php-src/issues/12695

Cheers,
Nicolas

--000000000000139e6e0652fa7279
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Dear internals,<br><br>Following the discussion around the=
 __exists() RFC, PR #22181 [1]=C2=A0isolates the engine-only piece that was=
 suggested there. The broader __exists() proposal=C2=A0remains on the table=
 separately; this PR is scoped to=C2=A0just the sequencing issue.<br><br>Wh=
en `??` or `empty()` triggers `__isset()` on a magic property and=C2=A0`__i=
sset()` writes into the property table (a pattern used in userland=C2=A0to =
lazily initialise a property), the engine currently calls `__get()`=C2=A0af=
terwards anyway. That redundant `__get()` is mostly cosmetic, but it=C2=A0c=
an trip up patterns where `__get()` routes through a parent that=C2=A0doesn=
&#39;t know about the just-materialised property.<br><br>The patch adds a p=
roperty-table re-check after `__isset()` returns=C2=A0true: if the property=
 now exists physically, the value is returned=C2=A0directly and `__get()` i=
s skipped. `isset()` itself is unchanged (it<br>has never called `__get()`)=
.<br><br>This sits between bug-fix and feature, so per the usual process:=
=C2=A0planning to merge to master in two weeks unless there are objections.=
<br><br>The PR has already been reviewed by @iluuu1994 and @arnaud-lb.<br><=
br>[1] <a href=3D"https://github.com/php/php-src/pull/22181">https://github=
.com/php/php-src/pull/22181</a><br>[2] <a href=3D"https://github.com/php/ph=
p-src/issues/12695">https://github.com/php/php-src/issues/12695</a><br><br>=
Cheers,<br>Nicolas<br></div>

--000000000000139e6e0652fa7279--