Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130812
Precedence: list
MIME-Version: 1.0
References: <CAOWwgp=sOZKN-ZoC-jUVa32tQHiqa8V+xP6t2Ozte+jmtih02A@mail.gmail.com>
 <CAPyj-LBZPtwqQ8u3mpBo9wyUhaW0zTARw_GsBimU3ULRABOX_w@mail.gmail.com>
In-Reply-To: <CAPyj-LBZPtwqQ8u3mpBo9wyUhaW0zTARw_GsBimU3ULRABOX_w@mail.gmail.com>
Date: Sat, 9 May 2026 15:14:42 +0200
Message-ID: <CAOWwgpkrUmiqfJ0te9kUyMQcKeG--82jRiejThZ2W4mZFL6JpQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] __exists(), a magic method for distinguishing
 "missing" from "set to null"
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008b11480651624cd4"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--0000000000008b11480651624cd4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Ilija,

Thanks for having a close look at the RFC.

Le ven. 8 mai 2026 =C3=A0 14:56, Ilija Tovilo <tovilo.ilija@gmail.com> a =
=C3=A9crit :

> Hi Nicolas
>
> Thanks for your proposal. I have some unpolished thoughts.
>
> On Fri, May 1, 2026 at 11:38=E2=80=AFAM Nicolas Grekas
> <nicolas.grekas+php@gmail.com> wrote:
> >
> > https://wiki.php.net/rfc/exists-magic-method
>
> From what I can tell there are two primary objectives stated in the RFC:
>
> 1. Solve the "null or undefined" ambiguity problem.
> 2. Allow materializing properties within the "property existence
> check" magic method, whether that be __isset() or __exists(), and
> avoiding the __get() call that normally follows.
>
> As for objective 1, it seems quite odd to me that __exists() indicates
> "the property is declared and may or may not be null", when is then
> used for all the constructs that ask the distinct question "is the
> property defined and not null?", namely for isset(), empty() (negated)
> and ??. That's the question already precisely answered by __isset().
> The behavior for disagreeing __isset() and __get() methods is odd, but
> IMO this is a clear userland bug.
>
> The other stated benefit is having the ability to check whether a
> property exists even if it may be null by calling __exists() directly.
> IMO the use-cases are narrow. For declared properties, there's a
> slightly unconventional solution: `array_key_exists('property',
> (array)$object)`. For virtual properties; fair enough. Though these
> could also use hooks nowadays.
>
> As for objective 2, you've mentioned this is possible to implement for
> __isset() but was rejected in GH-12695 due to complexity and
> performance concerns. IMO a new method does not address these
> concerns, it just moves them. If the __exists() method is intended to
> replace __isset() long-term, then, once all code has migrated,
> performance will not differ from adding the check to __isset(). [1]
> Similarly, complexity for implementing the __isset() and __exists()
> should be roughly equivalent. You solved the soundness issues
> mentioned in the RFC by avoiding repetition of the entire function and
> copying the relevant paths. I believe something similar should work
> for __isset().
>
> It's also worth noting the main objection in GH-12695 was to treat it
> as a bug and change behavior in stable versions.
>
> To summarize, in my personal opinion it's better to go back to the
> original idea and add another property existence check after the
> __isset() call that avoids calling __get() if the property has
> materialized. From what I can tell, the has_property handler will also
> need the same adjustments. I don't think the stated benefits are
> enough to warrant a full migration to a new method.
>
> Ilija
>
> [1] We also concluded in the issue that performance isn't a real issue
> anyway. __exists() would also perform worse due to having to call
> __get() to verify the value is not null. This does make sure the
> functions are in agreement, at the cost of an unnecessary call for
> correct code.
>

I would say that the two goals of the RFC are:

1. to indeed solve the "null or undefined" ambiguity problem.
2. to provide a solid primitive for true equivalence between magic
properties and regular ones.

About 1. it's a long standing issue for PHP objects: libs like
symfony/property-access / property-info have weird edge cases both in the
implementation and in the behavior that are unfixable unless PHP provides a
true way to separate between "null" and "undefined". You mention hooks:
those are great when the name of the properties are known ahead of time.
But that doesn't help when dealing with properties that are known only at
runtime. I nowadays see magic accessors as generic property hooks. It's a
powerful capability offered by the engine and it should work just great -
which it isn't at the moment.

About 2. the canonical broken behavior is that an expression like "$foo ??
123" MAY provide a NULL result. That's a big WTH for the type-system. I
agree that it should be considered a bug if one implements such a behavior
by mistake. Yet it's a foot-gun that the engine offered in the first place
- and it also opens for hacks (if not cracks) of the language semantics.
Something scary to me as a person engaged in making PHP better for years
now. A flaw from the past worth fixing, like many others we already fixed
along the years. Then yes, deprecating __isset may be considered later,
separately - it's just the cost for the community that needs to be
considered separately, and in a later version of PHP.

You also wrote that we can fix GH-12695 by implementing the materialization
check I added to __exists. It wasn't obvious to me that this would be an
acceptable move. That's good to read. Yet this alone wouldn't fix my main
concerns above.

About the double call to __get when using `isset($o->x) ? $o->x : $y`
that's indeed true. Yet it's not an issue to me: `??` is free from this
issue, has exactly the same semantics and is what ppl prefer using anyway
for this exact construct. In addition, __get calls usually start with a
hashtable check and are thus super quick - the double-call can be made
negligible in practice. Trading perf vs correctness in the case we discuss
should clearly balance towards correctness, that's the point of the RFC.
About `array_key_exists('prop', (array)$object)` that's of no use for magic
properties so that's unrelated.

I could certainly reformulate the RFC with a wording that aligns more
closely with this rationale. That wouldn't change what I propose at the
technical level, but that might help getting the points. Let me know.

Cheers,
Nicolas

--0000000000008b11480651624cd4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Ilija,<div><br></div><div>Thanks for h=
aving a close look at the RFC.</div></div><br><div class=3D"gmail_quote gma=
il_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 8 ma=
i 2026 =C3=A0=C2=A014:56, Ilija Tovilo &lt;<a href=3D"mailto:tovilo.ilija@g=
mail.com">tovilo.ilija@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">Hi Nicolas<br>
<br>
Thanks for your proposal. I have some unpolished thoughts.<br>
<br>
On Fri, May 1, 2026 at 11:38=E2=80=AFAM Nicolas Grekas<br>
&lt;<a href=3D"mailto:nicolas.grekas%2Bphp@gmail.com" target=3D"_blank">nic=
olas.grekas+php@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; <a href=3D"https://wiki.php.net/rfc/exists-magic-method" rel=3D"norefe=
rrer" target=3D"_blank">https://wiki.php.net/rfc/exists-magic-method</a><br=
>
<br>
From what I can tell there are two primary objectives stated in the RFC:<br=
>
<br>
1. Solve the &quot;null or undefined&quot; ambiguity problem.<br>
2. Allow materializing properties within the &quot;property existence<br>
check&quot; magic method, whether that be __isset() or __exists(), and<br>
avoiding the __get() call that normally follows.<br>
<br>
As for objective 1, it seems quite odd to me that __exists() indicates<br>
&quot;the property is declared and may or may not be null&quot;, when is th=
en<br>
used for all the constructs that ask the distinct question &quot;is the<br>
property defined and not null?&quot;, namely for isset(), empty() (negated)=
<br>
and ??. That&#39;s the question already precisely answered by __isset().<br=
>
The behavior for disagreeing __isset() and __get() methods is odd, but<br>
IMO this is a clear userland bug.<br>
<br>
The other stated benefit is having the ability to check whether a<br>
property exists even if it may be null by calling __exists() directly.<br>
IMO the use-cases are narrow. For declared properties, there&#39;s a<br>
slightly unconventional solution: `array_key_exists(&#39;property&#39;,<br>
(array)$object)`. For virtual properties; fair enough. Though these<br>
could also use hooks nowadays.<br>
<br>
As for objective 2, you&#39;ve mentioned this is possible to implement for<=
br>
__isset() but was rejected in GH-12695 due to complexity and<br>
performance concerns. IMO a new method does not address these<br>
concerns, it just moves them. If the __exists() method is intended to<br>
replace __isset() long-term, then, once all code has migrated,<br>
performance will not differ from adding the check to __isset(). [1]<br>
Similarly, complexity for implementing the __isset() and __exists()<br>
should be roughly equivalent. You solved the soundness issues<br>
mentioned in the RFC by avoiding repetition of the entire function and<br>
copying the relevant paths. I believe something similar should work<br>
for __isset().<br>
<br>
It&#39;s also worth noting the main objection in GH-12695 was to treat it<b=
r>
as a bug and change behavior in stable versions.<br>
<br>
To summarize, in my personal opinion it&#39;s better to go back to the<br>
original idea and add another property existence check after the<br>
__isset() call that avoids calling __get() if the property has<br>
materialized. From what I can tell, the has_property handler will also<br>
need the same adjustments. I don&#39;t think the stated benefits are<br>
enough to warrant a full migration to a new method.<br>
<br>
Ilija<br>
<br>
[1] We also concluded in the issue that performance isn&#39;t a real issue<=
br>
anyway. __exists() would also perform worse due to having to call<br>
__get() to verify the value is not null. This does make sure the<br>
functions are in agreement, at the cost of an unnecessary call for<br>
correct code.<br></blockquote><div><br></div>I would say that the two goals=
 of the RFC are:<br><br>1. to indeed solve the &quot;null or undefined&quot=
; ambiguity problem. <br>2. to provide a solid primitive for true equivalen=
ce between magic properties and regular ones.<br><br>About 1. it&#39;s a lo=
ng standing issue for PHP objects: libs like symfony/property-access / prop=
erty-info have weird edge cases both in the implementation and in the behav=
ior that are unfixable unless PHP provides a true way to separate between &=
quot;null&quot; and &quot;undefined&quot;. You mention hooks: those are gre=
at when the name of the properties are known ahead of time. But that doesn&=
#39;t help when dealing with properties that are known only at runtime. I n=
owadays see magic accessors as generic property hooks. It&#39;s a powerful =
capability offered by the engine and it should work just great - which it i=
sn&#39;t at the moment.<br><br>About 2. the canonical broken behavior is th=
at an expression like &quot;$foo ?? 123&quot; MAY provide a NULL result. Th=
at&#39;s a big WTH for the type-system. I agree that it should be considere=
d a bug if one implements such a behavior by mistake. Yet it&#39;s a foot-g=
un that the engine offered in the first place - and it also opens for hacks=
 (if not cracks) of the language semantics. Something scary to me as a pers=
on engaged in making PHP=C2=A0better for years now. A flaw from the past wo=
rth fixing, like many others we already fixed along the years. Then yes, de=
precating __isset may be considered later, separately - it&#39;s just the c=
ost for the community that needs to be considered separately, and in a late=
r version of PHP.<br><br>You also wrote that we can fix GH-12695 by impleme=
nting the materialization check I added to __exists. It wasn&#39;t obvious =
to me that this would be an acceptable move. That&#39;s good to read. Yet t=
his alone wouldn&#39;t fix my main concerns above.<br><br>About the double =
call to __get when using `isset($o-&gt;x) ? $o-&gt;x : $y` that&#39;s indee=
d true. Yet it&#39;s not an issue to me: `??` is free from this issue, has =
exactly the same semantics and is what ppl prefer using anyway for this exa=
ct construct. In addition, __get calls usually=C2=A0start with a hashtable =
check and are thus super quick - the double-call can be made negligible in =
practice. Trading perf vs correctness in the case we discuss should clearly=
 balance towards correctness, that&#39;s the point of the RFC.</div><div cl=
ass=3D"gmail_quote gmail_quote_container">About `array_key_exists(&#39;prop=
&#39;, (array)$object)` that&#39;s of no use for magic properties so that&#=
39;s unrelated.<br><br><div>I could certainly reformulate the RFC with a wo=
rding that aligns more closely with this rationale. That wouldn&#39;t chang=
e what I propose at the technical level, but that might help getting the po=
ints. Let me know.=C2=A0</div><div><br></div><div>Cheers,</div><div>Nicolas=
</div></div></div>

--0000000000008b11480651624cd4--