Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127928
Date: Mon, 07 Jul 2025 15:18:35 +0000
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.5
Message-ID: <RW5pVkI2UzsTt0LZQmpnpX96XnDSUGjwft-AXXkuDTZ6nV97sePVpHVHOipSQ0sX3VmGCQRTDZKhQqNr6TsDVFumcxJbzie-KChaladRuWk=@gpb.moe>
In-Reply-To: <CAPyj-LCwNznKQVpEQEiCPirMK5Xh+p9CFkhx8C68-3iUT09Bvg@mail.gmail.com>
References: <hzKdzBWWITU1ePjv3qcyK-OzroFAkWst9MQBw2zvKSA8pk1iqruLZZWTTh9gYDo2QX8EY_PiirVYDuwne2Upr3GlqZk570wtLOF49aaP-HQ=@gpb.moe> <CAPyj-LCwNznKQVpEQEiCPirMK5Xh+p9CFkhx8C68-3iUT09Bvg@mail.gmail.com>
Feedback-ID: 96993444:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

On Thursday, 3 July 2025 at 15:49, Ilija Tovilo <tovilo.ilija@gmail.com> wr=
ote:

> Hi everyone
>=20
> On Wed, Jul 2, 2025 at 9:58=E2=80=AFPM Gina P. Banyard internals@gpb.moe =
wrote:
>=20
> > It is this time of year again where we proposed a list of deprecations =
to add in PHP 8.5:
> >=20
> > https://wiki.php.net/rfc/deprecations_php_8_5
>=20
>=20
> Thanks for the bulk RFC. Some thoughts.
>=20
> > Deprecate __construct() and __destruct() in interfaces
>=20

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 ch=
opping board,
so this is punted to later with a comprehensive proposal.

>=20
> > Deprecate using values of type null and bool as array offsets and when =
calling array_key_exists()
>=20
>=20
> The introduction section also lists float as a type to be deprecated
> in array offsets:
>=20
> > Deprecate using values of type null, bool, and float as array offsets a=
nd when calling array_key_exists()
>=20
>=20
> 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
>=20
>=20
> 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()
>=20
>=20
> 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) =3D> spl_autoload_call($c)). It seems
>=20
> 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_autol=
oad_call() does NOT behave the same as passing it directly to the function.

Best regards,

Gina P. Banyard