Re: Re: [RFC][Dynamic class constant fetch]

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