On Thursday, 3 July 2025 at 15:49, Ilija Tovilo <tovilo.ilija@gmail.com> wrote:
> Hi everyone
>
> On Wed, Jul 2, 2025 at 9:58 PM Gina P. Banyard internals@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