Dear internals,
It's my pleasure to submit this new RFC to yours.
Please have a look and let me know:
https://wiki.php.net/rfc/exists-magic-method
TL;DR: I'm proposing a new opt-in magic method:
public function __exists(string $name): bool;
It'd let userland tell "set to null" apart from "missing" on objects, it'd
restore
isset() <=> ?? equivalence on magic properties, and it'd fixe GH-12695 as a
corollary. It's forward-compatible as a regular method on PHP <= 8.5
(probeable
via method_exists()), and would be magic on 8.6+.
Cheers,
Nicolas
Dear internals,
It's my pleasure to submit this new RFC to yours.
Please have a look and let me know:
https://wiki.php.net/rfc/exists-magic-methodTL;DR: I'm proposing a new opt-in magic method:
public function __exists(string $name): bool;It'd let userland tell "set to null" apart from "missing" on objects,
it'd restore
isset() <=> ?? equivalence on magic properties, and it'd fixe GH-12695
as a
corollary. It's forward-compatible as a regular method on PHP <= 8.5
(probeable
viamethod_exists()), and would be magic on 8.6+.Cheers,
Nicolas
Thanks for the very detailed RFC!
If it returns false, the fetch produces “uninitialized” (treated as null by ??, so y is evaluated). __get() is not called.
What is y? Looks like a reference to a previous iteration of the text.
The Sequencing section also doesn't describe the behavior when __exists() isn't defined. Does it just skip to step 4? (Please specify in the text.)
Is the intent to eventually deprecate __isset()? The RFC it doesn't now, but do you feel that is the eventual end-game, in PHP 10 or whatever?
The big one: Should any parallel changes or additions be made to property hooks? An exists() operation in addition to get/set, for instance? (I'm not sure at the moment, but it should be thought through and discussed, and if not, documented in the RFC.)
--Larry Garfield
Hi Larry,
Le sam. 2 mai 2026 à 17:47, Larry Garfield larry@garfieldtech.com a
écrit :
Dear internals,
It's my pleasure to submit this new RFC to yours.
Please have a look and let me know:
https://wiki.php.net/rfc/exists-magic-methodTL;DR: I'm proposing a new opt-in magic method:
public function __exists(string $name): bool;It'd let userland tell "set to null" apart from "missing" on objects,
it'd restore
isset() <=> ?? equivalence on magic properties, and it'd fixe GH-12695
as a
corollary. It's forward-compatible as a regular method on PHP <= 8.5
(probeable
viamethod_exists()), and would be magic on 8.6+.Cheers,
NicolasThanks for the very detailed RFC!
If it returns false, the fetch produces “uninitialized” (treated as null
by ??, so y is evaluated). __get() is not called.What is y? Looks like a reference to a previous iteration of the text.
The Sequencing section also doesn't describe the behavior when __exists()
isn't defined. Does it just skip to step 4? (Please specify in the text.)Is the intent to eventually deprecate __isset()? The RFC it doesn't now,
but do you feel that is the eventual end-game, in PHP 10 or whatever?The big one: Should any parallel changes or additions be made to property
hooks? An exists() operation in addition to get/set, for instance? (I'm
not sure at the moment, but it should be thought through and discussed, and
if not, documented in the RFC.)
Thanks for having a look!
I made some changes to clarify, see:
https://wiki.php.net/rfc/exists-magic-method?do=diff&rev2%5B0%5D=1777627745&rev2%5B1%5D=1777752909&difftype=sidebyside
y => $y
I added a description of the current sequencing of magic methods.
About deprecating __isset, I think it's way too early to consider doing it
for real. Still my answer is yes, but not on any timescale I can
anticipate. I added words about the doc, which should now encourage
__exists IMHO.
About hooks, that deserves a separate RFC to me. I've no intuition on this
as I don't use hooks often enough to feel the need for any missing "exists"
hook. If you still want my noob take on this: a hooked property exists -
because it has hooks. Not super helpful :D I added some words about this in
the RFC.
Cheers,
Nicolas
Hi Nicolas
Thanks for your proposal. I have some unpolished thoughts.
On Fri, May 1, 2026 at 11:38 AM Nicolas Grekas
nicolas.grekas+php@gmail.com wrote:
From what I can tell there are two primary objectives stated in the RFC:
- Solve the "null or undefined" ambiguity problem.
- 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.
Hi Ilija,
Thanks for having a close look at the RFC.
Le ven. 8 mai 2026 à 14:56, Ilija Tovilo tovilo.ilija@gmail.com a écrit :
Hi Nicolas
Thanks for your proposal. I have some unpolished thoughts.
On Fri, May 1, 2026 at 11:38 AM Nicolas Grekas
nicolas.grekas+php@gmail.com wrote:From what I can tell there are two primary objectives stated in the RFC:
- Solve the "null or undefined" ambiguity problem.
- 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:
- to indeed solve the "null or undefined" ambiguity problem.
- 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
Hi
Am 2026-05-09 15:14, schrieb Nicolas Grekas:
[…]
need the same adjustments. I don't think the stated benefits are
enough to warrant a full migration to a new method.
[…][…]
I now finally got around to reading your RFC in-depth and have also read
through the related GH-12695 issue to get the full picture.
I share Ilija's opinion in that this feels very much like a
“sledgehammer to crack a nut” approach to fix something that is
effectively the result of a userland implementation error in a feature
that nowadays has better replacements in many situations: Namely
forgetting to implement __isset() when __get() is implemented; and
not implementing a null check in __isset(). In fact the first issue
would not be solved by the proposal, since instead of forgetting to
implement __isset(), folks would just forget to implement
__exists().
Given that the RFC can naturally only ship in a new PHP version and
users will not upgrade right-away, it will take years until folks can
actually rely on the updated behavior and they will need to maintain
their existing workarounds until then. Specifically for the “lazy
proxies” use case that also was the motivation for GH-12695 my
understanding is that this is already solved in a much cleaner way since
PHP 8.4 with native lazy objects. Why would I want to wait for PHP 8.6
to be the baseline, when the better solution is already available with
8.4? Similarly other “lazy initialization” use cases for individual
properties can already be solved with property hooks in a cleaner way.
That leaves the “JsonRecord” use case, where the magic method doesn't do
anything by itself either, since folks would need to manually call it to
make the “exists but is null” distinction. It could just be a regular
method there - as already done in userland collection classes that just
have explicit ->has() and ->get() methods instead of relying on
magic methods. These notably also allow for much cleaner access to
fields that are not valid PHP identifiers (e.g. fields starting with a
digit or fields containing spaces).
I would treat this as a documentation issue, where it's not clearly
specified that users are expected to implement a null check in
__isset() and that users are expected to also implement __isset()
when implementing __get(). Perhaps the latter could even be made a
warning. That leaves the issue in GH-12695 which could then be fixed as
a master-only bugfix. While this would still require folks to carry
their workarounds until they can rely on PHP 8.6, it would not make the
language any more complex by requiring folks to learn yet another
pattern.
Best regards
Tim Düsterhus
Hi Tim,
Le ven. 29 mai 2026 à 12:01, Tim Düsterhus tim@bastelstu.be a écrit :
Hi
Am 2026-05-09 15:14, schrieb Nicolas Grekas:
[…]
need the same adjustments. I don't think the stated benefits are
enough to warrant a full migration to a new method.
[…][…]
I now finally got around to reading your RFC in-depth and have also read
through the related GH-12695 issue to get the full picture.I share Ilija's opinion in that this feels very much like a
“sledgehammer to crack a nut” approach to fix something that is
effectively the result of a userland implementation error in a feature
that nowadays has better replacements in many situations: Namely
forgetting to implement__isset()when__get()is implemented; and
not implementing anullcheck in__isset(). In fact the first issue
would not be solved by the proposal, since instead of forgetting to
implement__isset(), folks would just forget to implement
__exists().Given that the RFC can naturally only ship in a new PHP version and
users will not upgrade right-away, it will take years until folks can
actually rely on the updated behavior and they will need to maintain
their existing workarounds until then. Specifically for the “lazy
proxies” use case that also was the motivation for GH-12695 my
understanding is that this is already solved in a much cleaner way since
PHP 8.4 with native lazy objects. Why would I want to wait for PHP 8.6
to be the baseline, when the better solution is already available with
8.4? Similarly other “lazy initialization” use cases for individual
properties can already be solved with property hooks in a cleaner way.That leaves the “JsonRecord” use case, where the magic method doesn't do
anything by itself either, since folks would need to manually call it to
make the “exists but is null” distinction. It could just be a regular
method there - as already done in userland collection classes that just
have explicit->has()and->get()methods instead of relying on
magic methods. These notably also allow for much cleaner access to
fields that are not valid PHP identifiers (e.g. fields starting with a
digit or fields containing spaces).I would treat this as a documentation issue, where it's not clearly
specified that users are expected to implement anullcheck in
__isset()and that users are expected to also implement__isset()
when implementing__get(). Perhaps the latter could even be made a
warning. That leaves the issue in GH-12695 which could then be fixed as
a master-only bugfix. While this would still require folks to carry
their workarounds until they can rely on PHP 8.6, it would not make the
language any more complex by requiring folks to learn yet another
pattern.
Thanks for the review.
Treating magic accessors as legacy conflicts with how widely-used PHP code
actually works: Laravel Eloquent is built on __get/__set, and a long tail
of infrastructure sits on the same primitive, with legitimate use of them
(runtime-discovered properties typically).
Also: Native lazy objects don't cover laziness on userland subclasses of
internal classes, nor interface-based proxies or decorator patterns where
the target shape is dynamic.
Property hooks need declared property names, which is the constraint that
will continue to drive users to magic accessors in the first place.
If we agree magic accessors stay load-bearing (the alternative would be a
deprecation path that nobody is proposing), fixing their broken documented
semantics is maintainer responsibility.
The underlying issue isn't a userland implementation error: even
a perfectly null-checking __isset cannot distinguish "set to null"
from "missing" on a magic property.
The method returns one bit and is being asked two questions.
The ?? RFC also explicitly defines $x ?? $y as isset($x) ? $x : $y.
That contract is currently broken on magic properties. Documentation can't
fix a contract; the engine has to.
Patching __isset for GH-12695 alone doesn't restore it either; it would
need to change isset() semantics, a universal BC break.
On "people will just forget __exists": a class with only __get() today
produces broken isset() (always false) and empty() (always true).
Adding __exists() { return true; } fixes both for free. The "Recommended
floor for classes with __get" section in the RFC walks through this.
It is strictly less work than the existing __get + __isset pattern.
The "->has() / ->get() methods" suggestion is missing the point by
abandoning property syntax, which is the reason magic accessors exist in
the first place.
About __get-without-__isset (nor __exists), a warning could be fine to me
as an adjacent diagnostic.
I'd defer this to a follow up RFC, because this needs its own impact
analysis and is something related yet separate.
On the master-only property-materialization fix: as I noted to Ilija, I'm
fine with decoupling it from this RFC.
The remaining motivations (the structural ambiguity, the
documented-contract violation, the early-adoption convention via
method_exists()) stand on their own.
On the timeline concern: on PHP 8.5 and earlier, __exists() is a regular
method, so libraries can already probe method_exists($obj, '__exists') and
dispatch through it as a convention today. Adoption doesn't have to wait
for PHP 8.6 to be universally deployed.
Cheers,
Nicolas
Le ven. 29 mai 2026 à 14:42, Nicolas Grekas nicolas.grekas+php@gmail.com
a écrit :
Hi Tim,
Le ven. 29 mai 2026 à 12:01, Tim Düsterhus tim@bastelstu.be a écrit :
Hi
Am 2026-05-09 15:14, schrieb Nicolas Grekas:
[…]
need the same adjustments. I don't think the stated benefits are
enough to warrant a full migration to a new method.
[…][…]
I now finally got around to reading your RFC in-depth and have also read
through the related GH-12695 issue to get the full picture.I share Ilija's opinion in that this feels very much like a
“sledgehammer to crack a nut” approach to fix something that is
effectively the result of a userland implementation error in a feature
that nowadays has better replacements in many situations: Namely
forgetting to implement__isset()when__get()is implemented; and
not implementing anullcheck in__isset(). In fact the first issue
would not be solved by the proposal, since instead of forgetting to
implement__isset(), folks would just forget to implement
__exists().Given that the RFC can naturally only ship in a new PHP version and
users will not upgrade right-away, it will take years until folks can
actually rely on the updated behavior and they will need to maintain
their existing workarounds until then. Specifically for the “lazy
proxies” use case that also was the motivation for GH-12695 my
understanding is that this is already solved in a much cleaner way since
PHP 8.4 with native lazy objects. Why would I want to wait for PHP 8.6
to be the baseline, when the better solution is already available with
8.4? Similarly other “lazy initialization” use cases for individual
properties can already be solved with property hooks in a cleaner way.That leaves the “JsonRecord” use case, where the magic method doesn't do
anything by itself either, since folks would need to manually call it to
make the “exists but is null” distinction. It could just be a regular
method there - as already done in userland collection classes that just
have explicit->has()and->get()methods instead of relying on
magic methods. These notably also allow for much cleaner access to
fields that are not valid PHP identifiers (e.g. fields starting with a
digit or fields containing spaces).I would treat this as a documentation issue, where it's not clearly
specified that users are expected to implement anullcheck in
__isset()and that users are expected to also implement__isset()
when implementing__get(). Perhaps the latter could even be made a
warning. That leaves the issue in GH-12695 which could then be fixed as
a master-only bugfix. While this would still require folks to carry
their workarounds until they can rely on PHP 8.6, it would not make the
language any more complex by requiring folks to learn yet another
pattern.Thanks for the review.
Treating magic accessors as legacy conflicts with how widely-used PHP code
actually works: Laravel Eloquent is built on __get/__set, and a long tail
of infrastructure sits on the same primitive, with legitimate use of them
(runtime-discovered properties typically).
Also: Native lazy objects don't cover laziness on userland subclasses of
internal classes, nor interface-based proxies or decorator patterns where
the target shape is dynamic.
Property hooks need declared property names, which is the constraint that
will continue to drive users to magic accessors in the first place.
If we agree magic accessors stay load-bearing (the alternative would be a
deprecation path that nobody is proposing), fixing their broken documented
semantics is maintainer responsibility.The underlying issue isn't a userland implementation error: even
a perfectly null-checking __isset cannot distinguish "set to null"
from "missing" on a magic property.
The method returns one bit and is being asked two questions.
The??RFC also explicitly defines$x ?? $yasisset($x) ? $x : $y.
That contract is currently broken on magic properties. Documentation can't
fix a contract; the engine has to.
Patching __isset for GH-12695 alone doesn't restore it either; it would
need to change isset() semantics, a universal BC break.On "people will just forget __exists": a class with only __get() today
produces broken isset() (always false) and empty() (always true).
Adding__exists() { return true; }fixes both for free. The "Recommended
floor for classes with __get" section in the RFC walks through this.
It is strictly less work than the existing __get + __isset pattern.The "->has() / ->get() methods" suggestion is missing the point by
abandoning property syntax, which is the reason magic accessors exist in
the first place.About __get-without-__isset (nor __exists), a warning could be fine to me
as an adjacent diagnostic.
I'd defer this to a follow up RFC, because this needs its own impact
analysis and is something related yet separate.On the master-only property-materialization fix: as I noted to Ilija, I'm
fine with decoupling it from this RFC.
The remaining motivations (the structural ambiguity, the
documented-contract violation, the early-adoption convention via
method_exists()) stand on their own.On the timeline concern: on PHP 8.5 and earlier, __exists() is a regular
method, so libraries can already probe method_exists($obj, '__exists') and
dispatch through it as a convention today. Adoption doesn't have to wait
for PHP 8.6 to be universally deployed.
On the materialization aspect, I just submitted
https://github.com/php/php-src/pull/22181
It'd be great to have it reviewed/merged ASAP as that'd simplify the
discussion a bit here.
[image: :pray:] and thanks to anyone who can help make this happen.
Nicolas
Hi everyone,
Le ven. 1 mai 2026 à 11:37, Nicolas Grekas nicolas.grekas+php@gmail.com a
écrit :
Dear internals,
It's my pleasure to submit this new RFC to yours.
Please have a look and let me know:
https://wiki.php.net/rfc/exists-magic-methodTL;DR: I'm proposing a new opt-in magic method:
public function __exists(string $name): bool;It'd let userland tell "set to null" apart from "missing" on objects, it'd
restore
isset() <=> ?? equivalence on magic properties, and it'd fixe GH-12695 as a
corollary. It's forward-compatible as a regular method on PHP <= 8.5
(probeable
viamethod_exists()), and would be magic on 8.6+.
Are there any new comments on this RFC? I may start the vote this week-end
if not.
Let me know!
Cheers,
Nicolas
Hi
Are there any new comments on this RFC? I may start the vote this week-end
if not.
Let me know!
Two weeks of discussion are probably a little too short for an RFC of
this complexity and impact on long-standing semantics. As for myself:
Last week was mini-vacation + conference week (phpday 2026) and between
that and my day-job I did not yet have the time to give the RFC a proper
week, so I would like to ask for some additional time. I hope to be able
to give the RFC a first pass this week.
Best regards
Tim Düsterhus
Le lun. 18 mai 2026 à 22:25, Tim Düsterhus tim@bastelstu.be a écrit :
Hi
Are there any new comments on this RFC? I may start the vote this
week-end
if not.
Let me know!Two weeks of discussion are probably a little too short for an RFC of
this complexity and impact on long-standing semantics. As for myself:
Last week was mini-vacation + conference week (phpday 2026) and between
that and my day-job I did not yet have the time to give the RFC a proper
week, so I would like to ask for some additional time. I hope to be able
to give the RFC a first pass this week.
Of course, let me reset the counter today then. I'd be happy to gather more
feedback also, to be confident we have an informed consensus before opening
the vote.
Nicolas
Dear internals,
Le ven. 1 mai 2026 à 11:37, Nicolas Grekas nicolas.grekas+php@gmail.com a
écrit :
Dear internals,
It's my pleasure to submit this new RFC to yours.
Please have a look and let me know:
https://wiki.php.net/rfc/exists-magic-methodTL;DR: I'm proposing a new opt-in magic method:
public function __exists(string $name): bool;It'd let userland tell "set to null" apart from "missing" on objects, it'd
restore
isset() <=> ?? equivalence on magic properties, and it'd fixe GH-12695 as a
corollary. It's forward-compatible as a regular method on PHP <= 8.5
(probeable
viamethod_exists()), and would be magic on 8.6+.
Following the feedback received so far, you might have seen that I've split
the materialized property check into a separate PR/thread, see
https://externals.io/message/131068
I therefore updated the text of the RFC, now at v0.2, to account for that
materialization issue being addressed separately.
I also updated the wording to mention the points that have been discussed
and simplify the wording a bit (less repetitions, less C-side stuff).
I didn't update the implementation yet, but technically the TL;DR of this
new iteration is that it brings nothing new: it's only a refacto of the
presentation.
This message starts a new discussion period.
Cheers,
Nicolas
Hi there,
Le sam. 30 mai 2026 à 14:24, Nicolas Grekas nicolas.grekas+php@gmail.com
a écrit :
Dear internals,
Le ven. 1 mai 2026 à 11:37, Nicolas Grekas nicolas.grekas+php@gmail.com
a écrit :Dear internals,
It's my pleasure to submit this new RFC to yours.
Please have a look and let me know:
https://wiki.php.net/rfc/exists-magic-methodTL;DR: I'm proposing a new opt-in magic method:
public function __exists(string $name): bool;It'd let userland tell "set to null" apart from "missing" on objects,
it'd restore
isset() <=> ?? equivalence on magic properties, and it'd fixe GH-12695 as
a
corollary. It's forward-compatible as a regular method on PHP <= 8.5
(probeable
viamethod_exists()), and would be magic on 8.6+.Following the feedback received so far, you might have seen that I've
split the materialized property check into a separate PR/thread, see
https://externals.io/message/131068I therefore updated the text of the RFC, now at v0.2, to account for that
materialization issue being addressed separately.
I also updated the wording to mention the points that have been discussed
and simplify the wording a bit (less repetitions, less C-side stuff).I didn't update the implementation yet, but technically the TL;DR of this
new iteration is that it brings nothing new: it's only a refacto of the
presentation.This message starts a new discussion period.
Friendly before-opening-the-vote reminder about this RFC.
I plan to start the vote this Sunday.
Cheers,
Nicolas