Re: [RFC] Deprecations for PHP 8.5

On 07/07/2025 17:48, Gina P. Banyard wrote: > On Friday, 4 July 2025 at 08:04, Niels Dossche <dossche.niels@gmail.com> wrote: > >> Secondly, I'm tired of having to deal with useless deprecation messages. >> A lot of deprecation messages are completely useless for developers because they do not >> point to a reason or a replacement. >> That leaves you needing to look up the documentation, which is also incomplete. >> See https://github.com/php/php-src/issues/14320 >> Therefore, any deprecation proposed in this RFC that does not explicitly list the >> deprecation message, I will vote no for. > > I have added the deprecations messages for my own proposals, Thanks! > but I don't see this as a valid reason to vote against one. > The deprecation message is very much an implementation detail, and we should be able to improve > it at any point. True, and I have voted against things before due to implementation details. > > >> There are some things in the list I don't care about or I don't have a lot of >> insight of its uses in, and I will abstain for voting on them. >> >> There are a few things I will vote no for: >> >> [...] >> >> * Deprecate using values of type null and bool as array offsets and when calling >> array_key_exists() >> Deprecating this would make the language more inconsistent by allowing this on array >> offsets but not on the function. > > I am slightly confused by what you mean by "allowing this on array offsets but not on the > function". > However, null is not accepted by functions that accept scalar types, and bool would neither if > my other RFC is approved. > Moreover, a type declaration of int|string accepted Stringable objects, however array offsets > do not accept objects at all. I'll clarify: You're allowed to do $array[null], $array[3.14], etc... and the key will coerce. I expect array_key_exists() to behave the same way as keys on array accesses do. >> * Deprecate passing spl_autoload_call() to spl_autoload_unregister() >> This is very ad hoc, and as Ilija pointed out, we can't prevent workarounds for this. >> So what's the point really. >> The behaviour may be weird, but notice that people won't do this by accident. > > As replied to Ilija, and as Tim already mentioned, the workaround do NOT behave the same way as > passing the function directly. Yeah, I misunderstood this. Kind regards Niels