On Thursday, 3 July 2025 at 15:49, Ilija Tovilo <tovilo.il...@gmail.com> wrote:
> Hi everyone > > On Wed, Jul 2, 2025 at 9:58 PM Gina P. Banyard intern...@gpb.moe wrote: > > > It is this time of year again where we proposed a list of deprecations to > > add in PHP 8.5: > > > > https://wiki.php.net/rfc/deprecations_php_8_5 > > > Thanks for the bulk RFC. Some thoughts. > > > Deprecate __construct() and __destruct() in interfaces > We agreed with Tim to remove it from this RFC. We still think __destruct() in interfaces should be deprecated, but there are other interactions with __destruct() that should be on the chopping board, so this is punted to later with a comprehensive proposal. > > > Deprecate using values of type null and bool as array offsets and when > > calling array_key_exists() > > > The introduction section also lists float as a type to be deprecated > in array offsets: > > > Deprecate using values of type null, bool, and float as array offsets and > > when calling array_key_exists() > > > Floats used as array offsets that lose precision already emit a > warning. Can you confirm that floats used as array offsets that do not > lose precision will not start emitting a deprecation? Correct, that was a left over from a previous iteration. This should be fixed now. > > Deprecate ArrayObject and ArrayIterator with objects > > > Just to add another issue to the list: It can also change readonly > properties of internal classes that the engine does not expect to ever > change. For example, Enum::$name and Enum::$value. This can break > internal logic assumptions (e.g. hard-coded switch cases to handle > internal enums by name) and cause memory corruption. The same goes for > non-readonly properties guarded with the internal equivalent of > __set(). Added this as an example > > Deprecate passing spl_autoload_call() to spl_autoload_unregister() > > > Is such a check actually useful? We can prevent > spl_autoload_unregister(spl_autoload_call(...)), but we can't prevent > spl_autoload_unregister(fn($c) => spl_autoload_call($c)). It seems > > very unlikely for this to happen accidentally, and excluding all > functions that don't make sense to pass is not feasible for obvious > reasons. But I don't care too much. As Tim mentioned, this is not about preventing workarounds but removing the ability to "flush" the autoloading table. See https://3v4l.org/GVl7Z which showcases that a "proxy" call to spl_autoload_call() does NOT behave the same as passing it directly to the function. Best regards, Gina P. Banyard
