On Friday, 4 July 2025 at 08:04, Niels Dossche <dossche.ni...@gmail.com> wrote:
> Hi > > First of all, that's a huge list of deprecations and I think we should tone > down on that. > Especially if a feature still has a purpose and is not harmful or buggy, then > we should probably consider not deprecating it. The list of deprecation being "huge" is a consequence of more people working on php-src. We previously also had "large" deprecation RFCs like the one for 8.1, with some deprecations dropped. See: https://wiki.php.net/rfc/deprecations_php_8_1 Moreover, "harmful" is very much in the eyes of the beholder. > 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, 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. This is also *much* easier now that we can use the #[Deprecated] attributes on the majority of internals symbols, as that was one of the major limitations. > 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. > * Deprecate _debugInfo() returning null > Weird, especially as the docs say the return type is ": array", but not > harmful. Again, harmful here is very subjective. But as this is not my proposal, I will not comment further on it. > [...] > > * 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. > * Deprecate passing null to readdir(), rewinddir(), and closedir() > Dubious but not really harmful I think. I disagree that relying on implicit global state is not harmful. > * Based on Derick's comments I will vote no on the ext/filter deprecations. I > was already going to vote no on the filter* functions though. I have removed the functions anyway, however FILTER_DEFAULT is an incredibly problematic name, and not passing a filter is also problematic, so those remain on the RFC. > * Deprecate driver specific PDO constants and methods > Too early. I disagree with too early as the migrations for the constants is extremely easy and can be done by tools like Rector (or hell even sed if you feel adventurous) and the methods are effectively a hack on the PDO class which is already weird enough. Best regards, Gina P. Banyard
