Hi Nicolas
>> > https://wiki.php.net/rfc/dynamic_class_constant_fetch
>>
>
> I'm wondering about this:
>
> > This RFC proposes no change in the interaction between class constant
> > fetches and the null-coalescing operator ??. That is, Foo::{$bar} ?? null;
> > will throw an Error if the given constant does not exist. It would be
> > possible to suppress this error as is done for other types of member
> > accesses. However, it's not clear whether this is desirable, especially for
> > explicit class constant fetches. This change can be made in the future with
> > no backwards compatibility break.
>
> Since an argument in favor of the RFC is to replace a function call by native
> syntax, wouldn't it be desired to allow the same for checking the existence
> of a const? I'm thinking about defined(), which the ?? operator would nicely
> replace IMHO.
>
> Are there technical reasons to not do it in this RFC? If not, could this be
> considered?
It's not a technical reason. I was specifically asked to propose an
adjustment of interaction with ?? in a separate RFC because it is more
controversial. To be precise, suppressing undefined member errors for
`Foo::{$bar} ?? 'bar'` means we're also suppressing them for `Foo::BAR
?? 'bar'` (as we do for `$foo->bar ?? 'bar'`). Granted, we could make
an exception here but I don't think that is a good idea in terms of
consistency and user expectancy.
FWIW, I still think this change is worth making and I'm planning on
proposing this for PHP 8.3. I created a small proof of concept which
seems to indicate this is indeed possible, but there are some details
that need to be ironed out (like consistent isset/empty behavior,
consistent error suppression when chaining, etc).
Ilija
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
