On 07/07/2025 17:48, Gina P. Banyard wrote: > On Friday, 4 July 2025 at 08:04, Niels Dossche <dossche.ni...@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
